From wang!elf.wang.com!ucsd.edu!packet-radio-relay Sat Mar 23 21:42:10 1991 remote from tosspot
Received: by tosspot (1.63/waf)
	via UUCP; Sat, 23 Mar 91 20:35:56 EST
	for lee
Received: from somewhere by elf.wang.com
	id aa24637; Sat, 23 Mar 91 21:42:08 GMT
Received: from ucsd.edu by news.UU.NET with SMTP 
	(5.61/UUNET-shadow-mx) id AA06109; Sat, 23 Mar 91 15:12:49 -0500
Received: by ucsd.edu; id AA10456
	sendmail 5.64/UCSD-2.1-sun
	Sat, 23 Mar 91 04:30:27 -0800 for brian
Received: by ucsd.edu; id AA10451
	sendmail 5.64/UCSD-2.1-sun
	Sat, 23 Mar 91 04:30:14 -0800 for /usr/lib/sendmail -oc -odb -oQ/var/spool/lqueue -oi -fpacket-radio-relay packet-radio-list
Message-Id: <9103231230.AA10451@ucsd.edu>
Date: Sat, 23 Mar 91 04:30:06 PST
From: Packet-Radio Mailing List and Newsgroup </dev/null@ucsd.edu>
Reply-To: Packet-Radio@ucsd.edu
Subject: Packet-Radio Digest V91 #69
To: packet-radio@ucsd.edu


Packet-Radio Digest         Sat, 23 Mar 91       Volume 91 : Issue  69

Today's Topics:
                            Administrivia
                  ? how to route with tcpip (2 msgs)
             Anonymous ftp site for BayComm ??? (2 msgs)
                   anybody RUNNING 9600 ?? (2 msgs)
                                APLINK
                        Baycom Circuit Wanted
                 Class C IP address for packet radio?
                       Dayton - Digital Suite?
                       Digital repeater network
                    G3RUH 9600 baud users on UO-14
             Hierarchical Forwarding pounds (#) (13 msgs)
                   How to get email from packet???
                 Inadvertant "clear screen" (4 msgs)
                      KA9Q & mbox BBS forwarding
                        KA9Q v910308 problems
                      KAM dual-mode enhancement
          Monthly On-Line Elmers Resource Directory (2 msgs)
                           New packet user
                              No Subject
           Packet BBS SID and personal mbox reverse forward
                        PK-88 Pinouts (2 msgs)
                       portable packet (4 msgs)
                          SMTP Mail on PBBS?
                   STS-37 SAREX Information Summary
                          TAPR meeting notes
                                TCP/IP
                                Thanks
                The Amateur Radio BBS - How to access
                     The N2GTE Packet Mail Switch
                    TNC Emulators on PC's (3 msgs)
               WANTED: Docs for NETPC (DL3DBT v891105)
                     Where can I download Baycom?

Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu>
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Fri, 22 Mar 91 14:04:58 -0800
From: brian (Brian Kantor)
Subject: Administrivia
To: info-ham-digest, packet-radio-digest

Sorry about the deluge of digests; I just fixed the gateway and we had 10
days worth of traffic to catch up on.  Things should tame out now.

As many of you know, these mailing lists are gatewayed bidirectionally with
newsgroups on Usenet.  Recently those newsgroups underwent a reorganization,
with the ham-radio group being split into several groups, primarily splitting
off a "policy" group for the discussion of things like no-code, license
classes, rules and regulations, etc.

That newsgroup is now available as a separate digest from ucsd, the ham-policy
digest.  You may subscribe, as always, by sending mail to listserv@ucsd.edu.

Now that everything is working, I'm going on vacation for a week.  Flames will
be extinguished when I get back.
	- Brian

------------------------------

Date: 23 Mar 91 02:46:37 GMT
From: usc!samsung!munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@ucsd.edu
Subject: ? how to route with tcpip
To: packet-radio@ucsd.edu

In <1991Mar22.193108.10649@xanadu.com> jeff@xanadu.com (Jeff Crilly N6ZFX) writes:

>It seems that this should be doable without have to change the routing
>table (using arp and route add) on kg6kf.  If not, then everyone has to be
>able to hear everyone else; and only direct connections would be possible.

I haven't found a way yet. :-(  I have a similar problem here in Canberra.
Hidden Transmitters are the norm.  The only solution we have come up with
is to have every station you want to talk to that isn't direct pointed to
by a route and/or arp entry and they also have to have you defined.

We have another problem here in Australia.  IP routing isn't legal over the
air. (Yet, we're trying)  To talk to stations out of line of site we HAVE to
use digipeaters. :-(  Usually we end up having all the people we normally
talk to defined to ARP with a digipeater chain. :-(

Carl.

------------------------------

Date: 23 Mar 91 01:51:06 GMT
From: swrinde!zaphod.mps.ohio-state.edu!usc!apple!fernwood!portal!cup.portal.com!Jeepster@ucsd.edu
Subject: ? how to route with tcpip
To: packet-radio@ucsd.edu

>... So the question is, how can I get arp to send to kg6kf via wn6i-7 
>instead of replying directly?
 
You might try adding the following "route" entry:

ax25 route add kg6kf wn6i-7

That's what I had to do to get to a local tcp/ip station thru a digi.

John, KF0OU
jeepster@cup.portal.com
kf0ou@kf0ou.ampr.org [44.20.0.38]        Good luck, hope it helps!

------------------------------

Date: 13 Mar 91 16:44:03 GMT
From: bonnie.concordia.ca!s3!mlefebvr@uunet.uu.net
Subject: Anonymous ftp site for BayComm ???
To: packet-radio@ucsd.edu

I am looking for a anonymous ftp site from which I could get BayComm.
Is there such a site somewhere ? Thank you.

Marc, VE2HQI


 
--
Marc Lefebvre,                     IREQ: Institut de Recherche d'Hydro-Quebec
Analyste Ressources Informatiques        1802 Montee Ste-Julie, Varennes,
                                         Prov. Quebec, CANADA  J3X 1S1.
mlefebvr@ireq.hydro.qc.ca                Tel: 514 652-8554  fax: 514 652-8555

------------------------------

Date: 15 Mar 91 15:04:39 GMT
From: orion.oac.uci.edu!ucivax!jarthur!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!news.funet.fi!kannel!huopio@ucsd.edu
Subject: Anonymous ftp site for BayComm ???
To: packet-radio@ucsd.edu

> I am looking for a anonymous ftp site from which I could get BayComm.
> Is there such a site somewhere ? Thank you.

> Marc, VE2HQI

------------------------------

Date: 13 Mar 91 15:43:37 GMT
From: norand!lusere@uunet.uu.net
Subject: anybody RUNNING 9600 ??
To: packet-radio@ucsd.edu

I am interested in anyone's experiences in modifying and OPERATING
commercial and ham equipment to operate 4800-9600 baud packet.

This question is concerned with modifying FM radios for terrestrial links,
not satellite work through SSB equipment.

In particular, I'd like to hear any experiences with setting up the radios
and what performance figures are being seen (like dBm for 10-6 BER, 
bandwidths for various baudrates, deviation values that worked, radios 
that worked better than others, etc.)

I would like to try to use the older rock-bound commercial gear like Micors,
Maxars, MASTR EXEC's, etc.

Email is fine, I will summarize and re-post what I hear by that means.

Thanks,

Ron Luse, KD9KX
Norand Data Systems
Cedar Rapids, Iowa
uunet!norand!ron  |  norand!ron@uunet.uu.net  |  kd9kx @ wa0rjt.ia

------------------------------

Date: 13 Mar 91 18:52:48 GMT
From: brian@ucsd.edu
Subject: anybody RUNNING 9600 ??
To: packet-radio@ucsd.edu

In article <47@norand.UUCP> lusere@norand.UUCP (Ron Luse) writes:
>I am interested in anyone's experiences in modifying and OPERATING
>commercial and ham equipment to operate 4800-9600 baud packet.
>I would like to try to use the older rock-bound commercial gear like Micors,
>Maxars, MASTR EXEC's, etc.

I have been modifying several of these kinds of radios for 9600 bps
operation recently.

The MASTR Exec-II won't do it easily; it's got a phase modulator and
won't do flat dev.  The receiver works fine, so we'd thought about
shoving the modulation into the temperature compensation voltage line
to see if we could move the tempcomp varicap around to get true FM.
That might work, but we never got around to trying it.

The old lowband Mocom-70 will work at 9600 bps, but our experience is
that you really need to use them at 4800, because they have enough
frequency drift that the IF might wind up shaving off the edges of
received signals if one end is drifting opposite the other.

The MICOR will work just fine on 450 MHz, since there is a direct-FM
modulator on the TX offset oscillator.  The highband and some lowband
models have phase modulators, which won't work, and the serrasoid
modulator on lowband is hopeless.  I did have success in using a 450
channel element in a highband Micor TX, and shoving the modulation into
the AFC input of the element, but it wasn't real clean.  All bands have
plenty of receive IF bandwidth.

The Maxar is ideal because its transmitter has a direct-fm varicap
modulator.  You just pop one end of the 10uF DC blocking cap off and
feed the modem into there.  The receiver has sufficient IF bandwidth
but the detector is loaded down by the deemphasis network that hangs
off pin 6 of the detector chip; just chop off the 2.7k resistor and
take the output directly from pin 6 to the modem.

The Mitrek is pretty much the same as the MAXAR except that you have to
feed the transmit modulation directly into the modulation input line
for the channel element, since the previous stage is part of the
splatter lowpass filter.  We'll be using Mitreks on the hill since
they have a much better front end than the Maxar does.

Hope that helps.
	- Brian

------------------------------

Date: 20 Mar 91 02:20:42 GMT
From: swrinde!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!think.com!linus!linus!mwunix.mitre.org!m21198@ucsd.edu
Subject: APLINK
To: packet-radio@ucsd.edu

If that is not the required syntax for a posting a certain "Elmer" is 
going to suffer the Wouff Hong.

I, and I presume others, would like some information on APLINK bulletin
board systems.  They seem to be fairly common on hf Amtor and to be linked
with the national BBS system.  I would like to know:
  *  What is APLINK
  *  What can it do
  *  How is it linked to the rest of the world
  *  Where can the software to run it be obtained (APLINK 5.03)
  *  How is the frequency/band/beam heading scanning accomplished
  *  Any other lurid details:  Enquiring minds want, you know

Thanks:  John WA9FCH McHarry@MITRE.org

------------------------------

Date: 14 Mar 91 18:16:00 GMT
From: rosevax!bert.Rosemount.COM!mikef@uunet.uu.net
Subject: Baycom Circuit Wanted
To: packet-radio@ucsd.edu

I am looking for the schematic for the circuit as described in
the "BAYCOM" documentation.

I realize that there are boards available for the DIGICOM version,
but this requires an external power supply.

The circuit for the BAYCOM gets power from the RS232 port to power
the board.  The documentation suggests sending 89 Deutch Marks
to an adress in Germany, but I don't have a readily available
source for the Deutch Marks and I don't think that I want to send
cash (even German) thru the mail.  

I don't know how else to send for it or how long it would take
if I did find a way to order thru Germany. 

Does anyone have a copy of the schematic for this circuit or
suggestions on how to order it?

Mikef@bert.rosemount.com

------------------------------

Date: 19 Mar 91 03:52:39 GMT
From: usc!zaphod.mps.ohio-state.edu!uwm.edu!bionet!hayes.ims.alaska.edu!acad3.alaska.edu!ftpam1@ucsd.edu
Subject: Class C IP address for packet radio?
To: packet-radio@ucsd.edu

     I have some questions for the amateur radio IP community.  I have
an Arcnet LAN and have been thinking about getting a Class C IP network
address for it.  This would greatly simplify some projects that I am
working on.  However, there appear to be some pitfalls.  Questions follow:

1.   How many of you have Net 44 dependant routing?  For an example with
     KA9Q, Net 44 packets are routed to a KISS serial port and everything
     else is routed to a campus Ethernet ultimately connected to Internet.

2.   How many of you have amateur radio IP nodes with addresses outside
     Net 44?  Have you had problems with routing as described above?

Philip Munts N7AHL
NRA Extremist, etc.
University of Alaska, Fairbanks

------------------------------

Date: 18 Mar 91 18:24:16 GMT
From: pilchuck!ssc!tad@uunet.uu.net
Subject: Dayton - Digital Suite?
To: packet-radio@ucsd.edu

In article <3866@mjbtn.JOBSOFT.COM>, root@mjbtn.JOBSOFT.COM (Mark J. Bailey) writes:
> Hi,
> 
> Who all is planning to go to Dayton this year?  War's over, travel is probably
> getting safer again, economy may rebound....
> 
> Also, will there be another gathering of the "Digital Suite" at the Stouffer
> and if so, same place, same day (Friday) and time?

I organized the Digital Suite at Stouffers last year.  I'm not going to
Dayton this year.  The Digital Suite was a one time thing on my part.
A friend had reserved the Orville Wright Suite the year before, then
didn't use it.  He gave it to me for free, and I thought it would be
fun to gather usenet/fidonet/packet/RTTY hams for a party.  It
was great fun, but NO WAY could I ever afford to do this again, at
least with my money.


Tad Cook
Seattle, WA
Packet: KT7H @ N7ENT.#WWA.WA.USA.NA
Phone: 206/527-4089 
MCI Mail: 3288544 
Telex: 6503288544 MCI UW  
USENET:...uw-beaver!sumax!amc-gw!ssc!tad
or, tad@ssc.UUCP

------------------------------

Date: 13 Mar 91 21:29:21 GMT
From: sdd.hp.com!caen!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!cunixb.cc.columbia.edu!mig@ucsd.edu
Subject: Digital repeater network
To: packet-radio@ucsd.edu

Has anyone looked into the feasibility of creating a digital repeater network?
It seems to me that this would allow most any ham to talk to most any other,
anywhere, using a simple handheld radio. This seems like a logical extension
of the current plans to create an analog system using dynamic links to a
long distance backbone.  The problem with this scheme is:  what happens
if a link in the backbone fails; and if more than one user wants to use the
system at the same time?  It would be a very resource intensive system, 
anyway.

In short:  why couldn't the Amateur community set up the equivalent of a
digital cellular network with modest user requirements, linked exclusively
by radio and therefore immune to damage to the hard-wired systems such as
the telephone network.

Phil: can you hear me?
 * * * * * * *  ======================= Meir Green                 
* * * * * * * * ======================= mig@cunixb.cc.columbia.edu 
 * * * * * * *  ======================= N2JPG                      

------------------------------

Date: 14 Mar 91 19:01:54 GMT
From: swrinde!zaphod.mps.ohio-state.edu!samsung!rex!rouge!pc.usl.edu!jpd@ucsd.edu
Subject: G3RUH 9600 baud users on UO-14
To: packet-radio@ucsd.edu

Here's a list of users and their equipment summary, of satellite UO-14.
This pacsat operates at 9600 baud full duplex.

*UO-14 Users List rev.10            Compiled by JA6FTL  03-10-1990
========================
	Uploader:18 Countries 84 stations are counted (~ Mar.10)   
CT1DIA
DB2OS DD1EG DF5DP DL1YDD DL8NCI DF3LZ DL6KG DL1SBY
EA2ARU EA2CLS EA4BPN
G3YJO G4WFQ G8NOB G0K8KA G0MJW G3RUH G4AXC G8TZJ G3PJA
HB9BOM
I2KBD I3RUF IV3IBX I6CGE
JA6FTL JR1EDE JR1ING JA1OGZ JA1QHQ JH1TWZ
KF4WQ K8YAH K7PYK K8IRC  
      WC8J WA2LQQ W3QNS WB6YMH WD0E W7KRC W9FMW WB0KSL WA9FMQ WD3Q W3GYJ 
      N4HY NK6K N6HBB N5AHD N5BF N3FKV
LU8DYF
OH2SN OH2YU
ON6UG ON5PV ON4KVI
PE1CHL PA3DVG PE1HML PE1DNA
SM5BVF SM0TER
SV1IT SV3KH
UA3CR RK3KP
VK2BKQ VK3DTO VK5AGR VK7ZBX VK6BMD VK6VV VK5HI VK2XLG VK7ZBX VK3DFI VK2AIT
YN1UNI
ZL1AOX ZL1TRE ZL1TJK
***********************************************

*UO-14 USERS INFO (59 entries Mar.10) 
=====================================
CALL   ! name  ! MODEM ! ANT dwnlnk    ! RX dwnlnk   ! ANT trak ! uplnkPWR   !
       ! HM-BBS! TNC   ! ANT uplnk     ! TX uplnk    ! Freq trak! CPU  remarks*
-------------------------------------------------------------------------------
DB2OS  ! Peter ! G3RUH ! 2x20 XY Maspro! TS-811E     ! OSCAR-ST ! <50W       !
       ! DK0MAV! TNC2S ! 2x12 XY Maspro! TS-700G     ! -        ! AT286 16MHz!
DD1EG  ! Det   ! G3RUH ! 2x20 XY Maspro! IC-471H     ! AMSAT-DL ! <25W       !
       ! DB0IZ 1 TNC-2 ! 2x12 XY       ! FT-225RD    ! -        ! V-20 8MHz  !
DF3LZ  ! Roland! G3RUH ! 2x19 XY       ! C500        ! KCT      ! 10W        !
       ! DB0OQ ! TNC2C ! 2x12 XY       ! TS-700      ! -        ! AT386/387sx!
DF5DP  ! Bert  ! G3RUH ! 2x20 XY Maspro! FT726R      ! KCT      ! -          !
       ! DB0IZ ! TNC2A ! 2x12 XY       ! IC-475H     ! -        ! AT386 33M  !
DL1YDD ! Hart  ! G3RUH ! 2x7 3M BOOM   ! FT-780R+AMP ! HB TSR   ! 100W       !
       ! DB0IZ ! TNC2C ! 2x16 3M BOOM  ! FT-480R     ! -       !386/387 33MHz!
DL1SBY ! Axel  ! G3RUH ! 2x12 XY RHCP  ! IC-275      ! MANUAL   ! 100W       !
       ! -     ! TNC2C ! 2x20 XY RHCP  ! IC-475      ! -        ! AT 12MHz.  !
DL6KG  ! Hans  ! G3RUH ! 4x12 ele.horiz! FT-726R     ! MirageMTI! <25W       !
       ! DB0IE ! TNC-2 ! 2x9 wle XY    ! TS-711E     ! MANUAL   ! AT286 16MHz!
DL8NCI ! Matt  ! G3RUH ! 17 ele vert.  ! FT-726R     ! MANUAL   ! 10/100W    !*
       ! DB0GE ! TNC-2 !  7 ele vert.  ! FT-726R     ! MANUAL   ! 80286      !
EA2ARU ! JABI  ! G3RUH ! 2x19 XY TONNA ! TS-790S     ! KCT      ! 45W        !
       ! EA2RCG! TNC-2 ! 2x14 XY TONNA ! TS-790S     ! -        ! AT286 12MHz!
EA2CLS/! Tom   ! G3RUH ! KLM 435-40CX  ! TS-790A     ! KCT/     ! 45W        !
 kb7hta! EA2CDN! PK-88 ! KLM 2M-22C    ! TS-790A     ! -        ! AT386 33MHz!
EA4BPN ! Rafael! NB-96 ! 5/8+5/8 vert. ! TR-851E     ! -        ! 25W        !
       ! EA4URE! TNC-2 ! 19ele Hor.    ! TS-711E     ! -        ! AT286 16MHz!
G4AXC  ! Peter ! G3RUH ! 10 ele XY     ! FT-736      ! MANUAL   ! 25W        !
       ! PLYBBS! TINY2 ! 10t Helix     ! FT-736      ! MANUAL   ! 286        !
G4WFQ  ! Dave  ! G3RUH ! MBM88EL       ! FT736R      ! MANUAL   ! 25W        !
       ! GB7DDX! TNC220! KLM14C        ! FT736R      ! MANUAL   ! PC286 8MHz.!
G8TZJ  ! Andrew! G3RUH ! 17 el XY RHCP ! IC-471E     ! HB VIC-20! 60W        !
       ! GB7FCI! TINY2 !  6 el XY RHCP ! IC-211E     ! HB AFC   ! 8086 8MHz  !
I3RUF  ! GINO  ! G3RUH ! 1x21 orriz    ! TS-790E     ! KCT      ! 50W        !
       ! I3YPJ ! TNC200! 1x16 orriz    ! TS-790E     ! -        ! 386/387 33M!
I6CGE  ! Alfio ! G3RUH ! 2x17+17 ele   ! FT-736      ! KCT      ! <80W       !
       ! I6CGE !MFJ1270! 10+10 ele     ! TS-790      ! AUTO     ! 286 21MHz  !
IV3IBX ! FULVIO! G3RUH ! 2x19 XY       ! TS-790E     ! KCT      ! 50W        !
       ! IV3PFF! TNC2  ! 2x9 XY        ! TS-790S     ! -        ! 386/287 25M!
JA1OGZ ! Akira ! G3RUH ! 2x19 XY       ! FT-780      ! KCT      ! 30W        !
       ! JL1ZIJ! TNC-2 ! 12 XY         ! TR-9000+amp ! MANUAL   ! 5530z-SX   !
JA1QHQ ! Ehara ! G3RUH ! F9FT 19 XY*2  ! IC-371      ! MANUAL   ! 40W        !
       ! JL1ZIJ! TNC200! F9FT 9 XY     ! IC-251+amp  ! MANUAL   ! Dynabook   !
JH1TWZ ! nojyu ! G3RUH ! 2x25 vert     ! FT-736      ! MANUAL   ! 50W        !
       ! JL1ZIJ!TNC-20H! 2x12 vert     ! FT-736      ! MANUAL   !DynaBook(XT)!
JR1EDE ! Kohjin! NB96  ! -             ! TS-790S     ! KCT/IT1.0! 50W        !
       ! JL1ZIJ! TINY2 ! -             ! TS-790S     ! hb AFC   ! 386        !
JA6FTL ! sueo  ! NB96  ! 19 ele XY     ! TS-790S     ! KCT/IT1.0! 50W        !*
       ! JA6FTL!mPOWER2! 12 ele XY     ! TS-790S+amp ! hb AFC   ! 5530z-SX16M!
K7PYK  ! Wes   !PacComm! 2xKLM435-40CX ! FT-736R     ! KCT/QT   ! 125W       !
       ! K7PYK ! TNC-2 ! 2xKLM2M-22C   ! FT-736R     ! KCTune/QT! 386&286    !
K8IRC  ! BART  ! NB-96 ! 40ele KLM     ! FT-736      ! KCT      ! 25W        !
       ! KA0REW! TINY2 ! 20ele Cir.    ! FT-736      ! KCT-tuner! XT 10MHz   !
K8YAH  ! RON   ! NB96  ! 6 ele HORZ    ! IC-475A     ! MANUAL   ! 25/200     !
       ! W8CQK ! TNC200! 4 ele VERT    ! IC275A+amp  ! MANUAL   ! TURBO XT   !
OH2SN  ! Pate  ! G3RUH ! 19 ele XY     ! IC-490E     ! Auto     ! 150W       !
       ! OH2RBI! TNC2C ! 2x9 ele. HOR. ! IC-251/Mutek! Auto dplr! 386        !*
OH2YU  ! Sirpo ! G3RUH ! 2x17 XY RHCP  ! FT-736R     ! Auto PC  ! 20W        !
       ! OH2RBA! TNC-2 ! 2x10 XY RHCP  ! FT-736R     ! Manual   ! 386sx 16MHz!
ON4KVI !RENAULD! G3RUH ! 17ele XY      ! TS811       ! MANUAL   ! 100W       !
       ! ON7RC ! TNC2S !  9ele XY      ! TS711       ! MANUAL   ! PCXT 8MHz. !
ON5PV  ! PHIL  ! G3RUH ! 17ele V-H     ! FT-726R     ! MANUAL   ! 40W        !
       ! ON7RC ! TNC2S !  6ele V-H     ! TM221E      ! MANUAL   ! 286 16MHz  !
ON6UG  ! Freddy! G3RUH ! 2M Dish       ! FT-736R     ! HB Auto  ! 80W        !
       ! ON7RC ! TNC2C ! 9 ele XY      ! FT-736R     ! -        ! 386SX 16MHz!
PA3DVG ! AREND ! G3RUH ! 2x17 CD HOR.  ! FT-736R     ! KCT      ! 100W       !
       ! PI8JYL! PK87  ! 2x15 CD HOR.  ! FT-736R     ! KCT      ! 386 25MHz  !
PE1CHL ! Rob   ! G3RUH ! 2x15 XY RHCP  ! FT-712RH    ! fixed elv! 45W        !*
       ! PI8UTR! HB    ! 2x6  XY RHCP  ! FT-212RH    ! -        ! Atari520ST !
PE1HML ! Hendrik!G3RUH ! TURNSTYLE     ! FT-780      ! NONE     ! 12W        !*
       ! PI8ZAA!SCC8530! VERTICAL      ! FT-480      ! NONE     ! 8MHz PC    !
PE1DNA ! Joop  ! G3RUH ! 19ele Yagi    ! IC-475      !MANUAL(IT)! -          !
       ! -     ! none  ! 15ele Yagi    ! IC-275      ! -        ! AT clone   !*
RK3KP  !ClubSTn! NB96  ! 2x20 XY Maspro! FT-736R     ! KCT      ! -          !*
       ! RK3KP ! TINY2 ! 2x12 XY       ! FT-736      ! MANUAL   ! 286        !
SM0TER ! BRUCE ! G3RUH ! 4x14 SKEWED CP! TX790A      ! HB 8052  ! 45W        !
       ! SM0ETV! TINY2 ! 2x9  SKEWED CP! TX790A      ! HB AFC   ! COMPAQ286  !
SM5BVF ! HENLY ! G3RUH ! 2x13 skewed   ! IC-475      ! KCT      ! 50W        !
       ! SM0ETV! TNC200! 2x6  skewed   ! IC-275      ! HB       ! 386 16MHz  !
SV1IT  ! Kostas! G3RUH ! 9ele vertical ! TR851       ! MANUAL   ! 25W        !
       ! UOSAT3! TNC-2 ! 19ele vertical! TR751       ! MANUAL   !COMPAQLTE386!
SV3KH  ! Nick  ! NB96  ! 2x22ele K1FO  ! IC-475      ! MANUAL   ! 25W        !
       ! SV8RV !MFJ1270! 2x9ele TONA   ! IC-275      ! -        ! 386sx 16MHz!
UA3CR  ! Leo   ! G3RUH ! 9ele F9FT     ! FT-736      ! Fixed    ! -          !
       ! RK3KP ! TNC2  ! Helix 10T     ! FT-736      ! MANUAL   ! XT         !
VK2AIT ! Geoff ! G3RUH ! 15 ele HOR    ! FT-780R     ! MANUAL   ! <50W       !
       ! VK2XY ! TINY2 ! 12 ele HOR    ! FT-480R     ! MANUAL   ! 386 33MHz  !
VK3CFI/! Maggie! G3RUH !  Maspro       ! IC-251A     ! -        ! -          !*
 VK3DFI! VK3JAV!mPOWER2!  Maspro       ! IC-471H     ! -        ! T3100E     ! 
VK3DTO ! Andy  ! G3RUH ! 2x12 XY 18ver ! TS-711A     ! -        ! -          !
       ! -     !mPOWER2! 2x11 XY       ! TS811,IC490A! -        ! -          ! 
VK5AGR ! Graham! G3RUH ! 2x20 XY Maspro! IC-271A     ! KCT/IT1.0! 25W        !
       ! VK5WI ! PK87  ! 2x12 XY       ! IC-471A     ! MANUAL   ! AT286 12MHz!
VK5HI  ! Colin ! G3RUH ! 2x9 ele KLM   ! TS-700A     ! MANUAL   ! 10/100W    !
       ! -     ! TINY2 ! 2x7 ele KLM   ! TS-811A     ! MANUAL   ! 386sx 20MHz!
VK6BMD ! Bruce ! G3RUH ! 2x19 el vert  ! IC-471H     ! MANUAL   ! 25W        !
       ! VK6BBS! FRASH ! 1x17 el vert  ! IC-290H     ! MANUAL   ! XT 8MHz.   !
VK6VV  ! Arnold! G3RUH ! 16T Helical   ! TS-790A     ! MANUAL   ! 45W        !
       ! VK6BBS!PAD-205! 14 ele Vert   ! TS-790A     !JA6FTL AFC! AT286 16MHz!
VK7ZBX !Richard! G3RUH ! 16T Helix RHC ! FT-736R     ! MANUAL   ! 25W        !
       ! VK7GL ! PK-88 ! 10 XY RHC     ! FT-736R     ! MANUAL   ! 286 20MHz. !
W3GYJ  ! ROD   ! NB96  ! KLM44CX       ! FT-736R     ! KCT/QT4.0! 25W        !
       ! -     ! TINY2 ! CR144-20      ! FT-736R     ! KCT-Tuner! 386 25MHz. !
W7KRC  ! Wally ! NB96  ! KLM44CX       ! FT-726R     ! XCT/xt   ! 25W        !
       ! K7ZTM ! TINY2 ! KLM22C        ! FT-726R     ! MANUAL   ! Laptop12MHz!
W9FMW  ! Jack  ! NB96  ! 2xKLM 40CX    ! IC-475A     ! Graftrak ! 100W       !
       ! KA9LQM! TNC200! 2xKLM 22C     ! IC-274A+amp ! 2xKCT    ! 286 16MHz  !
WA2LQQ ! Rip   ! NB96  ! KLM435-40CX   ! TS-790A     ! KCT/GT   ! 45W        !
       ! WA2SNA! TNC-2 ! KLM2M-22C     ! TS-790A     ! KCTune/GT! 286 12Mhz. !
WA9FMQ ! Gary  ! NB96  ! KLM-14c       ! TS-790      ! KCT/QT4.0! -          !*
       ! -     !mPOWER2! KLM-22c       ! TS-790      ! KCT Tuner! Zeos386sx  !
WB6MPQ ! Al    ! NB-96 ! KLM-40C       ! FT-736      ! MANUAL   ! 50W        !
       !NN2Z.NJ! PK232 ! KLM-22C       ! FT-736      ! MANUAL   ! 386 20MHz  !
WC8J   ! Rich  ! G3RUH ! 20ele RH-XY   ! ICOM 471H   ! HB + IT  ! -          !
       ! -     ! 1270B ! 40ele XY      ! ICOM 275H   ! -        ! 286 16MHz  !
WD3Q   ! Eric  ! NB96  ! KLM-14c       ! TS-790      ! KCT      ! -          !*
       ! -     !mPOWER2! KLM-22C       ! TS-790      ! KCT-tuner! Zeos386sx  !
ZL1AOX ! Ian   ! G3RUH ! 15T HELIX RHC ! IC-475H     ! MANUAL   ! <75W       !
       ! ZL1AB !MFJ1270! KLM22C,5/8COLI! IC-275H     ! MANUAL   ! XT 10MHz   !
ZL1TRE ! Mark  ! G3RUH ! KLM40CX       ! TS-811A     ! MANUAL   ! 25W        !
       ! ZL1AB !MFJ1270! KLM22C        ! TS-711A     ! MANUAL   ! 386 26MHz  !
-------------------------------------------------------------------------------
Remarks
DL8NCI : developing own ftl0/bdcast s/w.
JA6FTL : AFC for 790/736 document is uploaded to this board.
PE1CHL : developing PACSAT s/w for Atari ST&PC,TCP/IP PE1CHL version with FTL0 
PE1HML : Using NET TCP/IP with ftl0 by PE1CHL
PE1DNA : No TNC's 2*OPtoPcScc card by PA0HZP (4 8530s)
RK3KP  : Amsat-U-Sputnik.Club Stn of Center of Science & Technology for Youth
VK3CFI : CFI:Maggie, DFI:Lou
WD3Q/WA9FMQ : VITA station in Rosslyn,VA,Washington.DC
OH2SN  : rx freq controled by 1khz steps with freq.calclat. tracking program
-------------------------------------------------------------------------------
        PLEASE give me your comment about this format and send your station 
information with above form via UO-14/AO-16/FO-20.IF you have general remarks,
Pse inform me within one line.

73s    SUEO ASATO  JA6FTL @ja6ftl.jnet6.jpn.asia

= = = = = = = = = = = = = = = = = = = =
Reposted (without permission ;-) by:


-- 
-- James Dugal,	N5KNX		Internet: jpd@usl.edu
Associate Director		Ham packet: n5knx@k5arh
Computing Center		US Mail: PO Box 42770  Lafayette, LA  70504
University of Southwestern LA.	Tel. 318-231-6417	U.S.A.

------------------------------

Date: 15 Mar 91 02:50:40 GMT
From: swrinde!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!matt.ksu.ksu.edu!steve@ucsd.edu
Subject: Hierarchical Forwarding pounds (#)
To: packet-radio@ucsd.edu

While using hierarchical addressing on the packet network, what is
the use of the pound (#) in the address.  An example would be:

KB0AGD @ K0VAY.#NEKS.KS.USA.NA

I realize that #NEKS means North East Kansas, but what is the #
for?  A flyback from the days of early sub-netting?

-Steve Schallehn, KB0AGD
 Kansas State University

------------------------------

Date: 18 Mar 91 15:23:41 GMT
From: mcsun!ukc!axion!kitkat!blloyd@uunet.uu.net
Subject: Hierarchical Forwarding pounds (#)
To: packet-radio@ucsd.edu

> 
> The main reason for having the # before the second field is to eliminate any
> problem which may arise from having a local hierarchical address which is
> the same as a country or continent designator. If, for example, you had a
> local address of NA (for Northern Australia, say), then the BBS would try to
                                                                  ^^^^^
> send the message to North America, as that is what NA is supposed to be.
> 
That should have been `might', rather than `would', depending on how the
forwarding file was set up. The important thing is that the BBS would have
to know the difference between NA meaning Northern Australia and NA meaning
North America.
	Brian

------------------------------

Date: 15 Mar 91 05:16:57 GMT
From: brian@ucsd.edu
Subject: Hierarchical Forwarding pounds (#)
To: packet-radio@ucsd.edu

In article <1991Mar15.025040.16086@maverick.ksu.ksu.edu> steve@matt.ksu.ksu.edu (Steve Schallehn) writes:
>While using hierarchical addressing on the packet network, what is
>the use of the pound (#) in the address.  An example would be:
>KB0AGD @ K0VAY.#NEKS.KS.USA.NA

The # (sharp, octothorp, hash, pound, etc ad nauseum) means that the
"regional" name following is a non-standardized one, as if the others
were more standardized.  In particular, it means that it's a more
localized routing indicator than ones that don't have the # in front of
them, and can be skipped without error if the station attempting to route
doesn't know what it means. (I.e., if you don't know what #NEKS means,
you may unhesitatingly skip over it and attempt to route at the KS.USA.NA)
(Note that the TELLUS.SOL.MW is implied in this address and need not be
supplied.)

Do not confuse these with the Internet hierarchical domains.  They don't
have any thing to do with the DNS, despite their identical format.  Grr.
	- Brian

------------------------------

Date: 19 Mar 91 10:44:24 GMT
From: ucselx!bionet!apple!mips!spool.mu.edu!munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@ucsd.edu
Subject: Hierarchical Forwarding pounds (#)
To: packet-radio@ucsd.edu

In <1991Mar18.150624.23335@axion.bt.co.uk> blloyd@axion.bt.co.uk (Brian Lloyd) writes:

>The idea of scanning from left to right is to find the most direct route to
>the destination. If I was to forward a message to you, the BBS would perform
>the following steps :
>If, on the other hand, I had a direct link to VK6BBS I would forward the
>message there, rather than to Australia, as VK6BBS is much closer to you
>Australia in general.

Hang on.  It would be stupid to route only on the first match.  I can't believe
Internet domain routers operate by only matching the first match from right to 
left!  

What you are saying is that EVERY segment of an address must be unique
world wide.  This, obviously, won't work!  The higher levels in the address
MUST be taken into consideration when making a match.

Carl.

------------------------------

Date: 19 Mar 91 02:50:20 GMT
From: munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!snap.adelaide.edu.au@THEORY.TN.CORNELL.EDU
Subject: Hierarchical Forwarding pounds (#)
To: packet-radio@ucsd.edu

Organization: Adelaide University
NNTP-Posting-Host: snap.adelaide.edu.au

Just a note about the H-addressing.

The new AA4RE v2.11 BBS software DOES now search like the internet
style. Eg if you have an address of,

   VK5ZWI@VK5TTY.#SA.AUS.OC

the AA4RE BBS can be set to search for,

VK5TTY.#SA.AUS.OC
#SA.AUS.OC
AUS.OC
OC

The first one that matches is the one that the mail will go to.

This means the # is no longer required. BUT I wouldnt go suggesting
it be dropped because there are still many BBS systems that dont
search that way.

Cheers de Grant VK5ZWI

   Grant Willis (VK5ZWI) - Adelaide University, South Australia -
         ** 2nd/3rd Year Electrical Engineering Student **
Packet Radio: VK5ZWI@VK5TTY.#SA.AUS.OC    AmPR TCP/IP: [44.136.171.11]
AARNet/Internet1: e2grwill@snap.adelaide.edu.au
ACSnet/Internet2: e2grwill@snap.ua.oz.au
Disclaimer: What I write is mine. The Uni has nothing to do with it!

------------------------------

Date: 18 Mar 91 15:06:24 GMT
From: mcsun!ukc!axion!kitkat!blloyd@uunet.uu.net
Subject: Hierarchical Forwarding pounds (#)
To: packet-radio@ucsd.edu



------------------------------

Date: 18 Mar 91 21:52:39 GMT
From: swrinde!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!hpa@ucsd.edu
Subject: Hierarchical Forwarding pounds (#)
To: packet-radio@ucsd.edu

In article <1991Mar18.150624.23335@axion.bt.co.uk> blloyd@zaphod.axion.bt.co.uk writes:
>The idea of scanning from left to right is to find the most direct route to
>the destination. If I was to forward a message to you, the BBS would perform
>the following steps :
>
>Do I know where VK6ZJM is?
>No - do I know where VK6BBS is?
>No - do I know where #WA is?
>No - do I know where AUS is?
>Yes - forward the message in that direction.

In proper domain-style addressing, a la the Internet, this would rather be:

Do I know where VK6ZJM.WA.AUS is?     No
Do I know where WA.AUS is?            No
Do I know where AUS is?               Yes
Forward in direction AUS

Note that the complete tail is a part of the address.  Thus, VK6ZJM.WA.AUS
could not be confused with, for example W0BBS.WA.US.NA; if my
(non-existent) system N9ITP.IL.US.NA connected it would try:

    W0BBS.WA.US.NA      Not found           VK6ZJM.WA.AUS      Not found
    WA.US.NA            Found -> forward    WA.AUS             Not found
                                            AUS                Found -> forward

See how easy it becomes?

           73 de N9ITP   U R 599+9600 BPS KN + @
-- 
hpa = H. Peter Anvin (in case you wondered) * Heja Sverige!
INTERNET:   hpa@casbah.acns.nwu.edu   FIDONET:  1:115/989.4
HAM RADIO:  N9ITP, SM4TKN             RBBSNET:  8:970/101.4

------------------------------

Date: 21 Mar 91 17:07:46 GMT
From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!munnari.oz.au!uniwa!cc.curtin.edu.au!nmurrayr@ucsd.edu
Subject: Hierarchical Forwarding pounds (#)
To: packet-radio@ucsd.edu

In article <1991Mar20.110655.23351@axion.bt.co.uk>, blloyd@axion.bt.co.uk (Brian Lloyd) writes:
> The problem comes when we
> comes across a sub-field which is not unique (eg #WA could be Western
> Australia or the Watsui province of Japan). The BBS somehow needs to know
> that there is a #WA in Australia and another one in Japan, and at present I
> don't think that's possible. What needs to be added, therefore, is some way
> of allowing the BBS to forward to #WA.AUS or #WA.JAP 

   This is the point I was trying to make in my original post. There IS such
a way, without adding anything. If you scan from right to left, with all fields
significant, then there's no ambiguity. To use your example, #WA.AUS is
obviously not the same as #WA.JAP, and any software that thinks it is clearly
brain-damaged. It's like telling someone that he can't call himself
"John Smith" because there's already a "John Jones" somewhere else in the
world, regardless of the fact that they're bound to have different higher-order
addresses (ie one lives in Sydney and the other lives in Oslo).

.....Ron
-- 

===============================================================================
 Internet: Murray_RJ@cc.curtin.edu.au                | "You can lead a horse to
 ACSnet: Murray_RJ@cc.cut.oz.au                      | water, but if you can
 Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet    | get him to float on his
 UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got
Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC       | something"
               TCP/IP: 44.136.204.14, 44.136.204.19  |    -- Murphy's Law I
===============================================================================

------------------------------

Date: 16 Mar 91 20:25:48 GMT
From: usc!apple!bionet!hayes.ims.alaska.edu!acad3.alaska.edu!ifjrs@ucsd.edu
Subject: Hierarchical Forwarding pounds (#)
To: packet-radio@ucsd.edu

In article <1991Mar15.025040.16086@maverick.ksu.ksu.edu>, steve@matt.ksu.ksu.edu (Steve Schallehn) writes...
>While using hierarchical addressing on the packet network, what is
>the use of the pound (#) in the address.  An example would be:
> 
>KB0AGD @ K0VAY.#NEKS.KS.USA.NA
> 
>I realize that #NEKS means North East Kansas, but what is the #
>for?  A flyback from the days of early sub-netting?
> 
This is an excerpt from documentation provided with AA4RE's BB
bulletin board program:

"W0RLI, VE3GYQ, and N6VV have devised a scheme called hierarchical
addressing.  Here's their description of their idea:

(stuff deleted)

"As an example, say that we send something to W0RLI @ W0RLI.CA.USA.NA,
and that the only entries that we have in the forward file are for 
CA.  That match would be sufficient to allow the message to be forwarded.
If W0RLI were found, that entry would take precedence (because
it is more left in the field than CA) and would of course also 
ensure delivery.  The best way to look at it is 'W0RLI AT W0RLI
which is in CA which is in USA which is in NA'.  So far so good.

But the Japanese network wants to use area routing numbers.  For
example, JA1ABC.42.JPN.AS ... and everyone says, 'So what, let 
them!'  Of course, that is very mature of all of us, but the trouble
is that the 42 in that string may also match wild-card ZIP codes
that some folks keep in their forward file, such as 42*.  The
solution we propose is to use an agreed upon key character for
designators below the state and province level, and we recommend
the octothorpe, '#'.

So now the above address would be JA1ABC @ JA1KSO.#42.JPN.AS ..."

(etc.)

Hope that explains a little more fully the reasoning ...

John

>-Steve Schallehn, KB0AGD
> Kansas State University

--

John Stannard
ifjrs@acad3.fai.alaska.edu		BITNET:  IFJRS@ALASKA
KL7JL@KL7JL.AK.USA.NA		kl7jl.ampr.org  [44.22.0.1]

"God is the Answer!"   "Oh?? ... er, ... What was the Question?"

--

------------------------------

Date: 21 Mar 91 01:49:06 GMT
From: sdd.hp.com!spool.mu.edu!munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@ucsd.edu
Subject: Hierarchical Forwarding pounds (#)
To: packet-radio@ucsd.edu

In <1991Mar20.110655.23351@axion.bt.co.uk> blloyd@axion.bt.co.uk (Brian Lloyd) writes:

>comes across a sub-field which is not unique (eg #WA could be Western
>Australia or the Watsui province of Japan). The BBS somehow needs to know
>that there is a #WA in Australia and another one in Japan, and at present I

Precisly.  The WHOLE address needs to be taken into consideration when
routing.  You cannot route to just "#WA".  You must route to "#WA.AUS.OC".

>> VK6ZJM) should ONLY be considered for routing purposes if it is shown as part
>I think that when someone moves the first person they tell (in the packet
>world) is the SYSOP of their local BBS, otherwise that BBS is going to keep
>trying to forward mail to them when they're not there. Being able to forward
>on the TO field is often very useful - remote SYSOPs often like to have mail
>addressed to SYSOP forwarded on to them, for example.

Forwarding on the TO field shouldn't be enabled.  The ONLY thing the TO
field should be used for is allowing the destination station (named in the TO)
to read his private mail.  It certainly shouldn't be used for forwarding.
Most (if not all) programs allow remapping of addresses.  If your remote
SYSOP (mentioned above) wanted to get his bulletins then they should be
remapped to SYSOP@<his BBS>.

Maybe things are different in the UK but here in Canberra I don't try to
forward mail to individual users.  They log on to my BBS to read it.  I
have 2 users who run PMSs who get mail forwarded and I have asked them to
detail their heirarchical addresses as; 
(for example)
vk1mc@vk1mc.vk1kcm.act.aus.oc
and no other BBS except me has to have routing information for them.
(I also remap vk1mc@vk1kcm to vk1mc@vk1mc.vk1kcm.act.aus.oc as few
amateurs understand heirarchical addressing. :-( )

The TO field on Bulletins is another story. :-(  It shouldn't be there
at all.

Carl.
vk1kcm@vk1kcm.act.aus.oc
skcm@ise.canberra.edu.au
3:620/241.7
[44.136.0.5][14][16] PC/BBS/Xenix

------------------------------

Date: 19 Mar 91 18:21:01 GMT
From: swrinde!zaphod.mps.ohio-state.edu!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!vision!mgc!dave@ucsd.edu
Subject: Hierarchical Forwarding pounds (#)
To: packet-radio@ucsd.edu

In article <1991Mar18.150624.23335@axion.bt.co.uk> blloyd@zaphod.axion.bt.co.uk writes:
>From article <7492.27e484b1@cc.curtin.edu.au>, by Murray_RJ@cc.curtin.edu.au (Ron Murray):
>> 
>> 1. The whole hierarchical forwarding process as implemented is a kludge (like
>>    half of the rest of packet's "protocols"): why in hell should it scan left
>>    to right when it makes more sense to scan right to left?
>
>The idea of scanning from left to right is to find the most direct route to
>the destination. If I was to forward a message to you, the BBS would perform
>the following steps :
>
>Do I know where VK6ZJM is?
>No - do I know where VK6BBS is?
>No - do I know where #WA is?
>No - do I know where AUS is?
>Yes - forward the message in that direction.
>

It's equally true to say:

Do I know where AUS is? Yes - continue; No - warn Sysop
Do I know where #WA is? Yes - continue; No - forward using AUS
Do I know where VK6BBS is ? Yes - continue; No - forward using #WA
Do I know where VK6ZJM is ? Yes - forward, No - forward using VK6BBS

So right to left is OK, too...and is much more in line with most other mail
system algorithms (although that might not count for much!). However, with
your method, you might get the answer:

VK6ZJM - no
VK6BBS - no
#WA - yes......it's the Watsui province of Japan, so send it there.

Right to left precedence is required.

And while I'm pontificating (:-) the left most callsign (in the above examples
VK6ZJM) should ONLY be considered for routing purposes if it is shown as part
of the domain segment (eg VK6ZJM.VK6BBS.#WA.AUS). Once the '@' is reached in
the right to left scan, routing should stop. The reason is this: the originator
of the message may know that VK6ZJM has moved QTH - routing software wouldn't
always know this.


-- 
Dave Lockwood          dave@mgc.uucp                 G4CLI@GB7DCC._199.GBR.EU
Head of Technology           ...!uunet!mcsun!ukc!vision!mgc!dave

MG Computer Systems Ltd, PO Box 50, Doncaster, DN4 5AW +44-302-738770

------------------------------

Date: 18 Mar 91 01:13:21 GMT
From: sdd.hp.com!samsung!munnari.oz.au!uniwa!vax7!nmurrayr@ucsd.edu
Subject: Hierarchical Forwarding pounds (#)
To: packet-radio@ucsd.edu

In article <1991Mar16.202548.18162@ims.alaska.edu>, ifjrs@acad3.alaska.edu (STANNARD JOHN R) writes:

 (quoting from the AA4RE documentation)
> 
> "As an example, say that we send something to W0RLI @ W0RLI.CA.USA.NA,
> and that the only entries that we have in the forward file are for 
> CA.  That match would be sufficient to allow the message to be forwarded.
> If W0RLI were found, that entry would take precedence (because
> it is more left in the field than CA) and would of course also 
> ensure delivery.  The best way to look at it is 'W0RLI AT W0RLI
> which is in CA which is in USA which is in NA'.  So far so good.
> 
> But the Japanese network wants to use area routing numbers.  For
> example, JA1ABC.42.JPN.AS ... and everyone says, 'So what, let 
> them!'  Of course, that is very mature of all of us, but the trouble
> is that the 42 in that string may also match wild-card ZIP codes
> that some folks keep in their forward file, such as 42*.  The
> solution we propose is to use an agreed upon key character for
> designators below the state and province level, and we recommend
> the octothorpe, '#'.
> 

   So far, it all seems to make sense (even if about as easy to read as Attila
the Hun's laundry list). Here in Australia they went a little further...

   If you look at my .sig below, you'll see the #WA between the BBS call and
the abbreviation for Australia. We were told that this was necessary (rather
than the much more obvious "WA" for Western Australia) because the hierarchical
forwarding software would assume that it was the abbreviation for Washington
state in the US because it scans the address from left to right. This leads me 
to conclude that either:

1. The whole hierarchical forwarding process as implemented is a kludge (like
   half of the rest of packet's "protocols"): why in hell should it scan left
   to right when it makes more sense to scan right to left? Internet domain
   names are scanned in this fashion. It's a bit like telling someone that he
   can't call himself "John Smith" because there's already a John Smith
   somewhere else. Or worse, that he has to call himself #Fred Bloggs because
   there's a Fred Bloggs in Outer Mongolia.

or

2. Someone in Australia mis-read the documentation and decided that this name
   change was necessary. This is probably the more likely.

Suggestions and corrections welcome.

....Ron

-- 

===============================================================================
 Internet: Murray_RJ@cc.curtin.edu.au                | "You can lead a horse to
 ACSnet: Murray_RJ@cc.cut.oz.au                      | water, but if you can
 Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet    | get him to float on his
 UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got
Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC       | something"
               TCP/IP: 44.136.204.14, 44.136.204.19  |    -- Murphy's Law I
===============================================================================

------------------------------

Date: 20 Mar 91 11:06:55 GMT
From: gatech!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!axion!kitkat!blloyd@ucsd.edu
Subject: Hierarchical Forwarding pounds (#)
To: packet-radio@ucsd.edu



------------------------------

Date: 20 Mar 91 21:27:34 GMT
From: swrinde!elroy.jpl.nasa.gov!usc!apple!erc@ucsd.edu
Subject: How to get email from packet???
To: packet-radio@ucsd.edu

I'm a relative newcomer to the world of packet radio, and am interested
in getting email via packet.  How might this be accomplished?  If someone
could point me to references, books, etc. that might help (something current)
I'd really appreciate it!

Ed Carp, N7EKG/6
Alameda, CA
-- 
Ed Carp  N7EKG/6	erc@khijol.UUCP		...uunet!khijol!erc
			Alameda, CA

Computers HAVE caused a revolution in how much information we
can safely ignore!    --robs@ux1.cso.uiuc.edu (Rob Schaeffer)

------------------------------

Date: 15 Mar 91 20:06:53 GMT
From: hpl-opus!hpnmdla!alanb@hplabs.hpl.hp.com
Subject: Inadvertant "clear screen"
To: packet-radio@ucsd.edu

In rec.radio.amateur.packet, andrem@pyrman2.pyramid.com (Andre Molyneux) writes:

>I've been experiencing an odd problem with my packet station.  Basically,
>my screen gets cleared by the transmissions of other stations.  The problem
...>developed as follows:

>I understand that I can set the TNC to filter out specific characters that
>are incompatible with the terminal in use.  Obviously ctrl-z is one of them,
>but I need to find what the other "clear screen" character is.  Any idea on
>how I should go about this? 

The ASCII "formfeed" character (12 decimal) is used as a "clear screen"
command by many terminals.

AL N1AL

------------------------------

Date: 18 Mar 91 19:37:51 GMT
From: swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac,
Subject: Inadvertant "clear screen"
To: packet-radio@ucsd.edu

In article <2285@ke4zv.UUCP> gary@ke4zv.UUCP (Gary Coffman) writes:
>formfeed will be one character you'll want to filter. Most nodes, and
>all TCP/IP stations transmit some packets in fully binary mode so you
>will often have characters on your screen in monitor mode that will

The 1.1.7 tapr firmware (MFJ adds WEFAX and calls it 1.2.7) includes
a MNONAX25 ON/OFF command, to eliminate tcp/ip, netrom routing, and
other packets having a PID different from that of AX.25.

73,
-- 
-- James Dugal,	N5KNX		Internet: jpd@usl.edu
Associate Director		Ham packet: n5knx@k5arh
Computing Center		US Mail: PO Box 42770  Lafayette, LA  70504
University of Southwestern LA.	Tel. 318-231-6417	U.S.A.

------------------------------

Date: 17 Mar 91 18:45:47 GMT
From: usc!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac,
Subject: Inadvertant "clear screen"
To: packet-radio@ucsd.edu

In article <148305@pyramid.pyramid.com> andrem@pyrman2.pyramid.com (Andre Molyneux) writes:
>I've been experiencing an odd problem with my packet station.  Basically,
>my screen gets cleared by the transmissions of other stations.  The problem
>developed as follows:
[deleted]
>I understand that I can set the TNC to filter out specific characters that
>are incompatible with the terminal in use.  Obviously ctrl-z is one of them,
>but I need to find what the other "clear screen" character is.  Any idea on
>how I should go about this?  (I've asked another packet operator to see if
>he get's any "unusual" characters from the node in question.  He reports
>that he doesn't see anything out of the ordinary when he connects to this
>node.)

Some TNCs have a filter command that removes all non-printing characters
from the incoming stream. I don't believe the MFJ 1274 is one of them.
I think you are limited to 10 characters in your filter list. Certainly
formfeed will be one character you'll want to filter. Most nodes, and
all TCP/IP stations transmit some packets in fully binary mode so you
will often have characters on your screen in monitor mode that will
cause your terminal to do strange things.  You'll need to sit down with
your terminal book and TNC manual and figure out what to kill.

Gary KE4ZV

------------------------------

Date: 14 Mar 91 23:39:46 GMT
From: pyramid!andrem@hplabs.hpl.hp.com
Subject: Inadvertant "clear screen"
To: packet-radio@ucsd.edu

I've been experiencing an odd problem with my packet station.  Basically,
my screen gets cleared by the transmissions of other stations.  The problem
developed as follows:

I bought a MFJ 1274 TNC and hooked it up to a XT clone using Procomm.
Everything ran fine.  Decided to free up the PC by getting a dedicated
terminal for packet.  Borrowed a Lee Data (don't remember the model #)
terminal from a friend, which ran in VT200 emulation mode.  Found that
the screen would get cleared everytime my TNC tried to display a packet
from a local node (SFO on 145.01 in the SF bay area).  I connected to
this node and found that any option I chose would result in a cleared
screen.

I didn't worry about it too much considering that the terminal was a
loaner.  Well, this past weekend I went to the Foothill College swapmeet
and picked up an old Televideo terminal (TVI 321???).  Fired it up and
found that it too would get its screen cleared by the same node.  In
addition, I found that the character used to indicate the end of a
message on mailboxes (ctrl-z), also clears the screen of the Televideo
(ctrl-z didn't bother the Lee Data).

I understand that I can set the TNC to filter out specific characters that
are incompatible with the terminal in use.  Obviously ctrl-z is one of them,
but I need to find what the other "clear screen" character is.  Any idea on
how I should go about this?  (I've asked another packet operator to see if
he get's any "unusual" characters from the node in question.  He reports
that he doesn't see anything out of the ordinary when he connects to this
node.)

+---------------------------------------------------+--------------------------+
| Andre Molyneux KA7WVV  andrem@pyrman2.pyramid.com |*** GENERIC DISCLAIMER ***|
+---------------------------------------------------+--------------------------+
|      -=-------- PYRAMID TECHNOLOGY CORPORATION    |All the usual disclaimers |
|    ---===------ 1295 Charleston Road              |apply although, as far as |
|  -----=====---- Mountain View, California 94043   |I can tell, my employer   |
|-------=======-- (415) 965-7200                    |doesn't care what I think!|
+---------------------------------------------------+--------------------------+

------------------------------

Date: 20 Mar 91 04:20:39 GMT
From: uhccux!uhcmtg.phys.hawaii.edu!tony@ames.arpa
Subject: KA9Q & mbox BBS forwarding
To: packet-radio@ucsd.edu

I need some assistance from any kind soul in mbox message forwarding.

I'm trying to setup a PC running KA9Q to forward messages to non-TCP/IP
stations.  Suppose I want messages for AH6BW to be forwarded to AH6BW@AH6BW-2
where AH6BW-2 is a different machine that doesn't handle TCP/IP.    

In my /alias file I have:

ah6bw ah6bw@ah6bw-10

In my /spool/forward.bbs file I have:

----
ah6bw-10
ax25 ax1 ah6bw-10
ah6bw
----

When the SMTP timer kicks in I get a message about ah6bw-10 being an unknown
host (as if it wants to deliver the message via TCP/IP and it fails on a
hostname lookup).  Shouldn't the entry in the forward.bbs file be enough to
tell NOS that ah6bw-2 is NOT a TCP/IP station?  What am I missing here?

I'm running the latest version of NOS from thumper.

Tony
AH6BW
tony@uhcmtg.phys.hawaii.edu
 

------------------------------

Date: 21 Mar 91 17:13:53 GMT
From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!munnari.oz.au!uniwa!cc.curtin.edu.au!nmurrayr@ucsd.edu
Subject: KA9Q v910308 problems
To: packet-radio@ucsd.edu

   When I run KA9Q version 910308 on my XT clone, it works fine on a SLIP link
to my AT at 9600 baud. If I try an AX25 connect to a non-TCP/IP system, it
crashes after a few K of data has been received. I don't think it happens
on a Telnet session over AX25, but I can't test it due to a complete lack of
other stations here in Perth running TCP/IP (Philistines!). It certainly
didn't crash the one time I tried a Telnet to it from someone else's computer,
but I might have been lucky.
   Has anyone else experienced this?

.....Ron
-- 

===============================================================================
 Internet: Murray_RJ@cc.curtin.edu.au                | "You can lead a horse to
 ACSnet: Murray_RJ@cc.cut.oz.au                      | water, but if you can
 Bitnet: Murray_RJ%cc.curtin.edu.au@cunyvm.bitnet    | get him to float on his
 UUCP  : uunet!munnari.oz!cc.curtin.edu.au!Murray_RJ | back you've really got
Amateur Packet Radio: VK6ZJM@VK6BBS.#WA.AUS.OC       | something"
               TCP/IP: 44.136.204.14, 44.136.204.19  |    -- Murphy's Law I
===============================================================================

------------------------------

Date: 17 Mar 91 00:44:36 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!maverick.ksu.ksu.edu!matt.ksu.ksu.edu!steve@ucsd.edu
Subject: KAM dual-mode enhancement
To: packet-radio@ucsd.edu

[hopefully there is enough interest to merit this reply]

A question came over the net a few weeks ago asking if a Kantronics
KAM could do both VHF packet and HF RTTY operation simultaneously.

After talking to Karl Medcalf of Kantronics, I have just found out
that Kantronics is testing new firmware to allow any HF operation and
VHF packet operation to occur at the same time on a Kantronics KAM.  
With the firmware upgrade and a specialized program running on a PC, 
one could, for example, log into a DX cluster and work RTTY at 
the same time.

Availability for the upgrade scheduled mid-spring.  Pricing for upgrades
is somewhere around $100.

---
-Steve Schallehn, KB0AGD
 Kansas State University

PS:  I am not affiliated with Kantronics.

------------------------------

Date: 15 Mar 91 18:16:15 GMT
From: swrinde!zaphod.mps.ohio-state.edu!caen!kuhub.cc.ukans.edu!zeus.unomaha.edu!acmnews@ucsd.edu
Subject: Monthly On-Line Elmers Resource Directory
To: packet-radio@ucsd.edu

As part of the multi-pronged strategy of Project SAVE THE BANDWIDTH, I 
will now put out a call for On-Line Elmers.  These are people, who by 
virtue of skill and knowledge in an area of expertise in ham radio, 
are willing to field E-mail by readers of the rec.radio.* groups.

Volunteers need only send me their name, E-mail address, and area of 
expertise.  "Generalists" or "Miscellaneous" Elmers are also quite 
welcome. Naturally, the more that volunteer, the more the work is 
distributed.  If upon volunteering, you are unable to meet your 
obligations, simply write to me and I will remove your name from the 
list.   I could also add that because of "personal committments" or 
"career broadening" you no longer are available to Elmer on a regular  
basis.

I will be the point-of-contact for this project.  I will maintain the 
list, post it to the groups at least monthly, and have the latest copy 
placed in the supplemental archives at ftp.cs.buffalo.edu in 
subdirectory pub/ham-radio.

Here is the latest version of the list.  If you sent me mail and are 
not on it, please resend as it may have been lost on the way or once 
it reached my host.

73, Paul, KD3FU

ACMNEWS@zeus.unomaha.edu  uunet!unocss!zeus!acmnews  137.48.1.1

ps67@umail.umd.edu        uunet!mimsy!umail!ps67     128.8.10.28            


ON-LINE Elmers Resource Directory (as of 03/15/91)
------------------------------------------------------

Dan Halbert, KB1RT
QTH is West Newton, MA, near Boston.

halbert@crl.dec.com

Building homebrew QRP gear, Advice on simple antennas

------------------------------------------------------

Paul W. Schleck, KD3FU

acmnews@zeus.unomaha.edu
ps67@umail.umd.edu

Miscellaneous, Internet, College Clubs

------------------------------------------------------

Mike Waters    AA4MW/7  

waters@nddsun1.sps.mot.com 

Miscellaneous

------------------------------------------------------ 

------------------------------

Date: 22 Mar 91 00:42:34 GMT
From: dog.ee.lbl.gov!ncis.tis.llnl.gov!lll-winken!uwm.edu!caen!kuhub.cc.ukans.edu!zeus.unomaha.edu!acmnews@ucsd.edu
Subject: Monthly On-Line Elmers Resource Directory
To: packet-radio@ucsd.edu

(Note:  Although less than a month has gone by, my list of volunteers
has nearly quadrupled.  Also, someone suggested that I add a list
of suggested areas of expertise.  So, here is the latest list...)

As part of the multi-pronged strategy of Project SAVE THE BANDWIDTH, I 
will be compiling a directory of On-Line Elmers.  These are people 
who, by virtue of skill and knowledge in an area of expertise in ham 
radio, are willing to field E-mail by readers of the rec.radio.* 
groups. 

Volunteers need only send me their name, E-mail address, and area of 
expertise.  As requested, here is a suggested list of areas of 
expertise that are needed: 

 1.  Volunteer Examiners
 2.  Novice Instructors
 3.  DX'ers and Contesters
 4.  QRP
 5.  Homebrewers
 6.  Packet Ops (both AX.25 and TCP/IP)
 7.  VHF and Repeaters
 8.  OSCAR and other satellites
 9.  MARS (Military Affiliate Radio System)
10.  CAP (Civil Air Patrol)
11.  ARES (Amateur Radio Emergency Service)
12.  RACES (Radio Amateur Civil Emergency Service)
13.  Skywarn (Amateur Weather Spotters)
14.  ARRL Field Organization (American Radio Relay League)

"Generalist" or "Miscellaneous" Elmers are also quite welcome. 
Naturally, the more that volunteer, the more the work is distributed.  
If upon volunteering, you are unable to meet your obligations, simply 
write to me and I will remove your name from the list.   I could also 
add that because of "personal committments" or "career broadening" you 
no longer are available to Elmer on a regular  basis. 

I will be the point-of-contact for this project.  I will maintain the 
list, post it to the groups at least monthly, and have the latest copy 
placed in the supplemental archives at ftp.cs.buffalo.edu in 
subdirectory pub/ham-radio.

Here is the latest version of the list.  If you sent me mail and are 
not on it, please resend as it may have been lost on the way or once 
it reached my host.

73, Paul, KD3FU

ACMNEWS@zeus.unomaha.edu  uunet!unocss!zeus!acmnews  137.48.1.1

ps67@umail.umd.edu        uunet!mimsy!umail!ps67     128.8.10.28            


ON-LINE Elmers Resource Directory (as of 03/21/91)
-----------------------------------------------------

John Brewer WB5OAU

brewer@anarky.enet.dec.com

Miscellaneous, Wire antennas,

------------------------------------------------------

Dan Halbert, KB1RT
QTH is West Newton, MA, near Boston.

halbert@crl.dec.com

Building homebrew QRP gear, Advice on simple antennas

-----------------------------------------------------
                                                                               
R.D. Keys  

Dept. of Crop Science 
NCSU
Raleigh, NC 27695-7620                
                                            
rdkeys@ccvr1.cc.ncsu.edu
                                   
de NA4G, "Boat Anchor Bob", an ol' cw fart .....                               
                                                                               
If I can be of assistance in older equipment, junk-boxing 
your way to hamdom, the cheapskate's approach, let me 
know.                                

22 yrs a ham, extra class, mostly cw, mostly boat anchors 
and radio in the traditional sense.                                 

{Telegraphy has been in my family for almost 100 years!}                       
                                                                               
------------------------------------------------------

Dave Potter, K1MBO

potter@think.com

electronics theory, regulations, antennas and 
transmission lines, operating practices.

------------------------------------------------------

Tony Reeves                                                                    
KK6XC                                                                          
QTH Beach Area of So. Los Angeles                                              
Torrance, Redondo Beach, Hermosa Beach, Manhattan beach                        
                                             
tony@hacgate.scg.hac.com
                                  
Novice training, local VE for Novice-Tech tests, 
General questions             

------------------------------------------------------

Paul W. Schleck, KD3FU

acmnews@zeus.unomaha.edu
ps67@umail.umd.edu

Miscellaneous, Internet, College Clubs

------------------------------------------------------

Tom Sefranek  WA1RHP            
                                   
tcs@ll.mit.edu                                                      

Elmering for the last 20 years.                                        
Almost all fields,                                                     
Specializing in power supplies, micro-controllers, antennas            
                                                                               
------------------------------------------------------
                                                                               
Diana L. Syriac                                                                
Leominster, MA                                                                 
dls@genrad.com                                                                 
KC1SP                                                                          
                                                                               
QSL Bureaus (how to use them)
Volunteer Examiner Service (how to become one)
Macintosh Hamstacks
Civil Air Patrol 

------------------------------------------------------

Mike Waters    AA4MW/7  

waters@nddsun1.sps.mot.com 

Miscellaneous

------------------------------------------------------ 

Bob Witte              HP Colorado Springs Division
bobw@col.hp.com        P.O. Box 2197
Phone:(719) 590-3230   Colorado Springs, CO  80901
Radio: KB0CY            
"All Disclaimers Apply."

Miscellaneous

-------------------------------------------------------

End of Directory

------------------------------

Date: 14 Mar 91 15:24:00 GMT
From: swrinde!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!boulder!bohemia!f510.n5000.z200.METRONET.ORG!Gary.Box@ucsd.edu
Subject: New packet user
To: packet-radio@ucsd.edu

Hi Clay and welcome to Ham Radio and Packet. I run packet with 
little more than a terminal program on an old CPM machine and it 
works fine. One thing you will need is some local help for finding 
your local BBS on packet; equipment set up; etc. Thats a little 
tough to do here. Once on the air, you can connect to the local BBS 
and send messages all over the world. Most BBS's have a help file 
that will describe the commands. While connected to any other packet 
station, or even to your own mailbox, your computer works as a 
terminal, so I would n't worry about operating system. Just have a 
terminal emulator program available. You can work up to a dedicated 
package like LanLink (which is for DOS) later.
By the way, when you get running send me a note. My call is N0JCG 
and my home BBS is WA0CQG. You would address a message to me at 
N0JCG @ WA0CQG. I think you'l like packet. I QSO with England, 
Greece and Israel regularly with it.
--- 
 * Origin: The Computer Lab (200:5000/510)

--  
=============================================================================
Gary Box - via MetroNet node 200:5000/301 
The Bohemia BBS System, Boulder Colorado (303)449-8946
UUCP:  Gary.Box@f510.n5000.z200.METRONET.ORG
 or :  ...!boulder!bohemia.METRONET.ORG!510!Gary.Box
=============================================================================

------------------------------

Date: 21 Mar 91 21:24:28 GMT
From: news-mail-gateway@ucsd.edu
Subject: No Subject
To: packet-radio@ucsd.edu



------------------------------

Date: 13 Mar 91 22:08:24 GMT
From: swrinde!zaphod.mps.ohio-state.edu!usc!apple!bionet!hayes.ims.alaska.edu!acad3.alaska.edu!ifjrs@ucsd.edu
Subject: Packet BBS SID and personal mbox reverse forward
To: packet-radio@ucsd.edu

In article <3091@oucsace.cs.OHIOU.EDU>, farrar@oucsace.cs.ohiou.edu (J. Craig Farrar) writes...
>Problem: Home BBS (MBL) will forward to personal mailbox in my TNC, but the TNC
>will not respond to the reverse forward poll when it sees it.
> 
(Stuff deleted)
> 
>The MBL board is a busy one and successfully forwards and reverse forwards
>with several neighboring boards.  The problem with the TNC mailboxes seems
>to be that they don't have a '$' in their SID.  That is reasonable since they
>are intended for private mail forwarding and not the flood forwarding that
>needs BID checking.  However, it causes the reverse forwarding to fail because
>the full-service BBS stations seem to require it.
> 
>Checking with the sysop of the MBL board we learn that this is a built-in
>feature and can't be changed.  Is this really true?  It would really be nice
>to have reverse forwarding work as it has been advertised, but we seem to have
>an impasse.  Do any of you in the net know a solution?
> 
A user here in Alaska has a KAM with the same problem--he adds the
SID _with_ the '$' in his "connect" text msg--it seems to work
quite well.  Hope this works for you in _your_ situation.

73, John

>---------
>J. Craig Farrar   farrar@oucsace.cs.ohiou.edu   W8UKE@KA8DRR.OH.USA.NA
>Ohio University, Athens, Ohio

--

John Stannard
ifjrs@acad3.fai.alaska.edu		BITNET:  IFJRS@ALASKA
KL7JL@KL7JL.AK.USA.NA		kl7jl.ampr.org  [44.22.0.1]

"God is the Answer!"   "Oh?? ... er, ... What was the Question?"

--

------------------------------

Date: 20 Mar 91 20:27:21 GMT
From: newstop!eastapps!Sun.COM!kerskine@sun.com
Subject: PK-88 Pinouts
To: packet-radio@ucsd.edu

I bought a PK-88 a few months ago and am now ready to use it, 
but I seem to have misplaced the manual.  Can anyone tell me 
the pinouts on the 8 pin tx/rc connector?

Thanks....Keith Erskine - KA1RHO

ps: I'm connecting this to an old Yaesu FT-22R 2M all-band.  Any 
special considerations I should know about? - thx ke

------------------------------

Date: 21 Mar 91 17:34:42 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!tandem!netcom!edg@ucsd.edu
Subject: PK-88 Pinouts
To: packet-radio@ucsd.edu

In article <4984@eastapps.East.Sun.COM> kerskine@Sun.COM (Keith Erskine - Sun Technical Marketing - Boston) writes:
>I bought a PK-88 a few months ago and am now ready to use it, 
>but I seem to have misplaced the manual.  Can anyone tell me 
>the pinouts on the 8 pin tx/rc connector?

	1	Ground		Brown
	2	Mic Audio	White
	3	Push-To-Talk	Red
	8	Receive Audio	Green
	7	Squelch Input	Black (optional)

Using the provided cable, follow the colors above to match up with the
manual, when you find it.  

By the way, I am reasonably computer literate, network literate and
radio literate and I wouldn't attempt to do much with this TNC without
the book.  It's worth getting another copy from AEA, since the TNC is
loaded with commands and features.
					-edg
-- 
Ed Greenberg, WB2GOH/6
San Jose, CA
edg@netcom.COM		

------------------------------

Date: 17 Mar 91 02:39:05 GMT
From: ogicse!unicorn!n9041169@ucsd.edu
Subject: portable packet
To: packet-radio@ucsd.edu

I do not own a packet 
although I am thinking about buying one soon, one thing you might try though is purchasing one of the new breed of "notebook" size pc laptops.  Most I have
seen come with serial and parallel ports, vga lcd, screen and a fair amount 
of memory, and a 1.44mb 3.5in disk - all for between 1800-3600$.  Zeos, Austin
and a few others all make IBM compatible machines with 80286 12-16hz processors
for about 2000 dolloars.  Take a look in the March Computer Shopper for a run-
down on most the latest of these notebook sized machines weighing generally 
less than 6lb.
                  hope you find what you're looking for,
                            Chris

------------------------------

Date: 14 Mar 91 19:37:07 GMT
From: swrinde!cs.utexas.edu!ut-emx!ccwf.cc.utexas.edu!wdlee@ucsd.edu
Subject: portable packet
To: packet-radio@ucsd.edu

I am planning a cross country expedition (by *RAIL*) and would like
to take along my packet radio system. I have a couple of issues I'd like
to discuss:

DUMB TERMINALS (or, 'Why is this lap-top so heavy?')
My girlfriend agreed to loan me her laptop computer (bless her heart)
but it just HURLS RF at 145.01 MHz. In addition, I'd just use it to run
PROCOMM anyway. (It weighs more than my entire packet setup!)
So I was at the mall this morning and saw something that
I found intriguing (as Cmdr. Data would say). Have you seen the Casio
B.O.S.S. model SF-9500? or model SF-800? These are little clock, calendar,
memo, telephone number, rolodex, scratch your back, do everything hand-held
LCD display things with little alpha-numeric keypads... and guess what...
There's a serial port on the little guy and the literature states that
"you can hook it up to your PC..."!
Has anyone heard of any sort of modern little hand held LCD thing being used
as a dumb (RS232) terminal? I'd only need a couple of lines (with scrollback
perhaps) and I'd let my TNC do all the work.

In closing, the other issue I was concerned about is...
Should I even bother attempting to try 2 meter work from within a
huge steel rail car moving at 80 mph? I love trains and have traveled coast
to coast more than 10 times (I don't fly), and I have met other hams aboard
the train with their HT's by their side. What do you think?
All aboard!
David
their HT's on their belts

------------------------------

Date: 14 Mar 91 22:40:55 GMT
From: sdd.hp.com!zaphod.mps.ohio-state.edu!know!tegra!vail@ucsd.edu
Subject: portable packet
To: packet-radio@ucsd.edu

In article <45605@ut-emx.uucp> wdlee@ccwf.cc.utexas.edu (david lee) writes:

   DUMB TERMINALS (or, 'Why is this lap-top so heavy?')
   My girlfriend agreed to loan me her laptop computer (bless her heart)
   but it just HURLS RF at 145.01 MHz. In addition, I'd just use it to run
   PROCOMM anyway. (It weighs more than my entire packet setup!)
   So I was at the mall this morning and saw something that
   I found intriguing (as Cmdr. Data would say). Have you seen the Casio
   B.O.S.S. model SF-9500? or model SF-800? These are little clock, calendar,
   memo, telephone number, rolodex, scratch your back, do everything hand-held
   LCD display things with little alpha-numeric keypads... and guess what...
   There's a serial port on the little guy and the literature states that
   "you can hook it up to your PC..."!
   Has anyone heard of any sort of modern little hand held LCD thing being used
   as a dumb (RS232) terminal? I'd only need a couple of lines (with scrollback
   perhaps) and I'd let my TNC do all the work.

I had the idea of connecting tha cable from my BOSS into the speaker
jack of my IC-24, put a NOS prompt on the screen and send it in to QST
as portable packet.

The answere to your question is: no.  The BOSS will transfer data to
another computer running the appropriate software with a simple Intel
Hex based protocol.  There is no "terminal mode" although I bet Casio
could sell a few more BOSSs if they added one.

The BOSS is a really neat and useful device although the only amateur
radio uses I have found for it are alternate time (GMT) and saving
repeater control codes and frequency information for reference.


"theobromine: a compound which, contrary to it's name,
contains neither bromine nor God" -- David Throop
 _____
|     | Johnathan Vail | n1dxg@tegra.com
|Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet)
 -----  jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail

------------------------------

Date: 16 Mar 91 15:45:34 GMT
From: swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac,
Subject: portable packet
To: packet-radio@ucsd.edu

In article <45605@ut-emx.uucp> wdlee@ccwf.cc.utexas.edu (david lee) writes:
>I am planning a cross country expedition (by *RAIL*) and would like
>to take along my packet radio system. I have a couple of issues I'd like
>to discuss:
>
>DUMB TERMINALS (or, 'Why is this lap-top so heavy?')

A friend of mine uses his Sharp Wizard with a pocket packet TNC. The
major problems are the screen and keyboard being smaller than standard.
Most packeteers format their messages for 80 column and this makes it
hard to read on a 40 col display. Secondly, the keyboards on these little
jewels aren't really suited to touch typing. Keyboard QSOs are slow anyway,
but having to hunt and peck on the little keyboard makes it intolerable
to me anyway. The new Wizard (the one with the QWERTY keyboard) has a 
serial port that works up to 9600 baud. I don't know the baud rates
available on the BOSS series. I have another friend who has one of 
these and I'll ask him. The consensus around here is that the Wizard
is a better value than the BOSS, but if you're only going to use it
as a terminal, then that probably doesn't matter. 

One lightweight system I've used for portable packet is the Radio
Shack Mod 100. It suffers from the 40 col screen, but the keyboard is
decent and it has a built in terminal program. Used Mod 100s should
be lots cheaper than the BOSS or the Wizard. RCA used to make a simple
dumb terminal with a 2 line 80 col display and a full size keyboard.
These are a little smaller than a Mod 100 and I've seen them at
hamfests for $25.

Your HT should work fine on the train. I'd make a twinlead J-pole
and tape it to a window for best results. Between your terminal and
your TNC, there should be enough digital hash that I'd want to locate
the antenna a few feet from the noise. Also the extra gain of the
J-pole will help on voice too.

Do be aware that train power may not be 110 VAC 60 Hertz. So battery
elimination or charging may become a problem if you don't have the
proper adapters. Check this out ahead of time with your travel agent
or call the train company's maintence yard and talk to their electrician.

Have fun!

Gary KE4ZV

------------------------------

Date: 19 Mar 91 03:45:33 GMT
From: ARDSLEY.BUSINESS.UWO.CA!Mark@ucbvax.berkeley.edu
Subject: SMTP Mail on PBBS?
To: packet-radio@ucsd.edu

I have been using KA9Q nos for quite a while now.  I am interested in trying
something else for awhile.  Unforunately, I don't find NOS stable enough, or
quick enough for AX25 use.  I would like to have a bbs program that supports
SMTP mail plus the messages come in as one file per user.  Does anyone know of
such a program?  There is MSYS here, but it stores each message separately.

Any ideas?


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mark Bramwell, VE3PZR                Located in sunny London, Ontario

Internet: Mark@ARDSLEY.business.uwo.ca  IP Address: 129.100.29.33
  Packet:  VE3PZR @ VE3GYQ               UWO Phone: (519) 661-3714

------------------------------

Date: 21 Mar 91 17:13:28 GMT
From: agate!eos!aio!gamorris@ucbvax.berkeley.edu
Subject: STS-37 SAREX Information Summary
To: packet-radio@ucsd.edu

STS-37 SAREX
Shuttle Amateur Radio EXperiment
Information Summary
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============================================================

SAREX Introduction

STS-37 Crew:
  N5RAW, Steve Nagel, Mission Commander
 KB5AWP, Ken Cameron, Pilot
  N5QWL, Jay Apt, Mission Specialist
  N5RAX, Linda Godwin, Mission Specialist
  N5SCW, Jerry Ross, Mission Specialist

SAREX equipment on this flight includes a 2m (144-146 Mhz) Motorola radio
(output 2.3 watts), Robot 1200C slow scan convertor, Heath HK-21 packet TNC,
a 70cm FSTV receiver, a video camera, and a Monitor/VCR.  Planned operations
include voice contacts, packet robot, downlinking orbiter video via SSTV,
uplinking FSTV video to the orbiter. 

During sleep periods and when no other SAREX activities are scheduled the
equipment will be left on in packet robot mode.  If time permits the crew
will setup SAREX to transmit SSTV using orbiter video cameras during the GRO
satellite release and during the EVA.  The GRO satellite release is
scheduled for MET 2/03:00 (2 days 3 hours after launch) for 1 hour.  The EVA
is scheduled for MET 2/22:00 thru MET 3/05:00.  With 5 hams on the flight
there may be many unscheduled opportunities for operation, I suggest you
monitor both downlink frequencies on all passes starting with orbit 1 until
landing, even during sleep periods you could hear something other than
packet.  Contacts between the shuttle and school children will be
retransmitted by W5RRR, see timeline for times, and W5RRR frequency
information below. 

============================================================

Keplerian Element Set

STS-37
1 00037U          91 94.64868056  .00023000           17236-3 0    49
2 00037  28.4683 237.6443 0006982 279.6613  80.3332 15.37985111    23

Satellite: STS-37
Epoch time:      91094.64868056
Element set:     JSC-004
Inclination:       28.4683 deg          Space Shuttle Flight STS-37
RA of node:       237.6443 deg              Keplerian Elements
Eccentricity:     .0006982            from pre-launch post OMS-2 vector
Arg of perigee:   279.6613 deg          Launch:  04 APR 91  14:20 UTC
Mean anomaly:      80.3332 deg
Mean motion:   15.37985111 rev/day                 W5RRR
Decay rate:       2.30E-04 rev/day^2      NASA Johnson Space Center
Epoch rev:               2

============================================================

SAREX Uplink/Downlink Frequencies

Downlink/Uplink Frequencies for Voice/Packet/SSTV to be used on Upcoming
Mission

Get out your HTUs and HT programming manuals.  You will want to program your
2 meter FM transceivers with the following information.  Note that only
stations with prior arrangements can uplink FSTV signals (special
authorization is required from the FCC).  It is expected that uplinking FSTV
will require about 15kw ERP.  FSTV ops and 2m can occur simultaneously. 

Mode           Downlink Freq Uplink Freq
-------------- ------------- -----------
Voice/SSTV     145.55        144.95 (primary), 144.91, 144.97
Packet         145.51        144.91 (primary), 144.93, 144.99
FSTV           none          70cm band

Please note that the frequencies they will be listening for stations ARE
DIFFERENT than the one they will transmit on.  This is a very important fact
to understand.  They will transmit to earth (downlink) on a single frequency
145.55 MHz for voice and SSTV.  They will listen for stations transmitting
to the shuttle (uplink) on the other frequencies listed.  This "split"
operation is used quite successfully by DXers when operating in an
environment where large pile ups are expected. 

There will be no simplex operation with SAREX on either voice or packet. 
Although packeteers are not accustomed to operation with a TX/RX offset, in
this case, it is the only way to connect to SAREX.  If you transmit on
145.55 or 145.51 MHz the only people who will hear you are those other Hams
in your area trying to hear the shuttle. 

============================================================

SAREX Packet Operating Hints

FULLDUP OFF
DWAIT   0.1 - 0.5 seconds
FRACK   > 3.0 seconds
C KB5AWP

The packet call sign on board the shuttle is KB5AWP (SSID=0).  Your TNC
should be in half-duplex mode (FULLDUP OFF) with CD active just like you do
for normal VHF packet operations.  If you can compensate for doppler shift
it is worth the extra effort.  The bandwidth of the SAREX radio is +/-4Khz,
maximum doppler is around 3.3Khz.  If you canUt compensate for doppler your
best chance for contact is when the shuttle is at peak elevation at your
site. 

You should be careful with the setting of two of your TNC's timers: DWAIT
and FRACK.  DWAIT is the time interval after your Carrier Detect light goes
out and before your transmitter turns on.  You want to make sure your
connects requests and ACKs are contained in the 3 second FUDtimer window. 
If everybody runs the same DWAIT (like the typical 0.1 - 0.5 second values
used for terrestrial packet), then everybody will be transmitting at the
same time.  Part of the key to your success when uplink QRM is heavy is to
pick a DWAIT that nobody else is using!  (sort of like picking a lottery
number!)

FRACK sets the time interval between your transmissions.  After you send a
frame, your TNC waits for the FRACK time, and then waits for the Carrier
Detect signal to drop, then waits DWAIT, and then tries again.  You should
make sure your FRACK is at least 3 seconds so that you are not transmitting
when the robot's FUDtimer decides it is time for it to transmit -- if you
are transmitting at the same time, you will miss any packets the shuttle is
addressing to you and you won't have a successful QSO. 

Note that your DWAIT (how soon do I transmit?) and FRACK (then how long do I
wait?) parameters and the need to stop transmitting so you can hear a reply
are just like you encounter when working a DXpedition pileup on HF.  If the
DX station has a pattern of listening for a few seconds (=FUDtimer) before
transmitting, you may have better luck being the LAST station they hear,
after the din dies down.  The differences are that (1) the robot is a
computer and is very predictable and (2) the robot can be working several
stations at one time. 

============================================================

Mission Audio Retransmissions

The following stations will retransmit the mission audio from the shuttle
and ground controllers. 

WA3NAN - Goddard Space Flight Center (GSFC), Greenbelt, Maryland.
W5RRR  - Johnson Space Center (JSC), Houston, Texas
W6VIO  - Jet Propulsion Laboratory (JPL), Pasadena, California.
W6FXN  - Los Angeles
K6MF   - San Francisco
W4MWG  - Mebane, NC

Station    VHF     10m     15m     20m    40m    80m
------   ------  ------  ------  ------  -----  -----
WA3NAN   147.45  28.650  21.395  14.295  7.185  3.860
W5RRR    146.64
W6VIO    224.04          21.340  14.270
W6FXN    145.46
K6MF     145.58                          7.165  3.840
NASA/JSC 171.15
W4MWG                            14.230 (SSTV)

============================================================

W5RRR Special Event Station

W5RRR - Johnson Space Center (JSC) ARC, Houston, TX.  Special event station
with bulletins, updated element sets, and current flight information will be
making contacts and answering questions using SSB on the HF bands.  The
frequencies are listed below.  The special event station will start after
launch and run up thru landing.  W5RRR will also retransmit the audio from
the contacts between STS-37 and schools.  Three of the 5 bands will be in
use at any given time, band selection will be determined by propagation
(usually 10/15/20m daytime, 20/40/80m night). 

Station  10m     15m     20m    40m    80m
-----  ------  ------  ------  -----  -----
W5RRR  28.400  21.350  14.280  7.227  3.850   (+/- QRM)

============================================================

W1AW Voice Bulletins

W1AW will be broadcasting daily bulletins with updated information on SAREX
during the flight.  Voice bulletins are transmitted daily at 0230 UTC and
0530 UTC on the following frequencies:

Station  10m     15m     17m     20m    40m    80m
-----  ------  ------  ------  ------  -----  -----
W1AW   28.590  21.390  18.160  14.290  7.290  3.990

============================================================

AMSAT Net Operations

Information will also be available from the AMSAT net, tune in for
bulletins.  The net operates every week on:

    Sunday  1800-2100 UCT (international)  14.282 Mhz USB
    Tuesday 0130-0300 UCT (USA)             3.840 Mhz LSB

============================================================

JSC INFO BBS

The Public Affairs Office at the Johnson Space Center operates a BBS to
provide information to the public.  Check this board for updates to the
keplerian element sets during the flight. 

To access the BBS, call +1-713-483-2500 using 1200 baud, 8-N-1, at the ENTER
NUMBER: prompt, enter "62511" and you will be connected to the BBS.  Check
file area 30 or 99 for latest element sets. 

NASA JSC's Electronic Space Information BBS is intended to provide 24-hour
access to biographies of NASA officials and astronauts, news releases, space
flight mission presskits and television schedules, space shuttle systems
information, flight manifests and schedules, and other information about the
space program. 

============================================================

NASA Select Video Broadcast

The continental United States will receive NASA Select television, 24 hours
a day throughout the mission, via:

SATCOM F2R
Transponder 13
72 degrees West Longitude
3960 MHz (Video)
6.8 MHZ (Audio)

============================================================

STS-37 SAREX Timeline (unofficial summary)

               MET                                                (ST/DST)**
UTC          D  H  M Rev     Event                            PT     CT     ET
-----------  ------- --- ----------------------------------- ---- -------- ----
4/4/91 1420  0 00 00   1 LAUNCH                              0620 4/4 0820 0920
4/4/91 2115  0 06 55   5 Start SAREX Setup                   1315 4/4 1515 1615
4/4/91 2120  0 07 00   5 Begin Pre-Sleep Activity            1320 4/4 1520 1620
4/4/91 2140  0 07 20   5 Finish SAREX Setup                  1340 4/4 1540 1640
4/5/91 0020  0 10 00   7 Begin Sleep Period                  1620 4/4 1820 1920
4/5/91 0820  0 18 00  12 Begin Post-Sleep Activity           0020 4/5 0220 0320
4/5/91 1120  0 21 00  14 End Post-Sleep Activity             0320 4/5 0520 0620
4/5/91 1210  0 21 50  15 Cabin depress to 10.2 PSI           0410 4/5 0610 0710
4/5/91 1332  0 23 12  16 AOS FSTV w/N9AB, US Bridge          0532 4/5 0732 0832
4/5/91 1350  0 23 30  16 LOS FSTV w/N9AB, US Bridge          0550 4/5 0750 0850
4/5/91 1511  1 00 51  17 AOS School #1 via US Bridge         0711 4/5 0911 1011
4/5/91 1529  1 01 09  17 LOS School #1 via US Bridge         0729 4/5 0929 1029
4/5/91 1649  1 02 29  18 AOS School #2 via US Bridge         0849 4/5 1049 1149
4/5/91 1707  1 02 47  18 LOS School #2 via US Bridge         0907 4/5 1107 1207
4/5/91 1829  1 04 09  19 AOS School #3 via US Bridge         1029 4/5 1229 1329
4/5/91 1845  1 04 25  19 LOS School #3 via US Bridge         1045 4/5 1245 1345
4/5/91 2020  1 06 00  20 Begin Pre-Sleep Activity            1220 4/5 1420 1520
4/5/91 2020  1 06 00  20 AOS School #4 via SA Bridge         1220 4/5 1420 1520
4/5/91 2041  1 06 21  20 LOS School #4 via SA Bridge         1241 4/5 1441 1541
4/5/91 2320  1 09 00  22 Begin Sleep Period                  1520 4/5 1720 1820
4/6/91 0720  1 17 00  27 Begin Post-Sleep Activity           2320 4/6 0120 0220
4/6/91 1020  1 20 00  29 End Post-Sleep Activity             0220 4/6 0420 0520
4/6/91 1120  1 21 00  30 GRO Grapple                         0320 4/6 0520 0620
4/6/91 1130  1 21 10  30 GRO Unberth                         0330 4/6 0530 0630
4/6/91 1230  1 22 10  30 GRO Solar Array Deploy              0430 4/6 0630 0730
4/6/91 1350  1 23 30  31 GRO High Gain Antenna Deploy        0550 4/6 0750 0850
4/6/91 1431  2 00 11  32 AOS FSTV w/W5RRR, KE4PT w/US Bridge 0631 4/6 0831 0931
4/6/91 1451  2 00 31  32 LOS FSTV w/W5RRR, KE4PT w/US Bridge 0651 4/6 0851 0951
4/6/91 1730  2 03 10  34 GRO Release                         0930 4/6 1130 1230
4/6/91 2020  2 06 00  35 Begin Pre-Sleep Activity            1220 4/6 1420 1520
4/6/91 2320  2 09 00  37 Begin Sleep Period                  1520 4/6 1720 1820
4/7/91 0720  2 17 00  42 Begin Post-Sleep Activity           2320 4/7 0020 0120
4/7/91 1020  2 20 00  44 End Post-Sleep Activity             0120 4/7 0320 0420
4/7/91 1020  2 20 00  44 Begin EVA Prep                      0120 4/7 0320 0420
4/7/91 1210  2 21 50  46 Unscheduled SSTV/Packet             0310 4/7 0510 0610
4/7/91 1235  2 22 15  46 Airlock Depress/Egress              0335 4/7 0535 0635
4/7/91 1340  2 23 20  47 Unscheduled SSTV/Packet             0440 4/7 0640 0740
4/7/91 1510  3 00 50  48 Unscheduled SSTV/Packet             0610 4/7 0810 0910
4/7/91 1640  3 02 20  49 Unscheduled SSTV/Packet             0740 4/7 0940 1040
4/7/91 1850  3 04 30  50 Airlock Ingress/Repress             0950 4/7 1150 1250
4/7/91 1935  3 05 15  50 Begin Pre-Sleep Activity            1035 4/7 1235 1335
4/7/91 2235  3 08 15  52 Begin Sleep Period                  1335 4/7 1535 1635
4/8/91 0535  3 15 15  57 Begin Post-Sleep Activity           2035 4/7 2235 2335
4/8/91 0835  3 18 15  59 End Post-Sleep Activity             2335 4/8 0135 0235
4/8/91 0835  3 18 15  59 Cabin repress to 14.7 PSI           2335 4/8 0135 0235
4/8/91 1314  3 22 54  62 AOS School #5 US Bridge             0414 4/8 0614 0714
4/8/91 1333  3 23 13  62 LOS School #5 US Bridge             0433 4/8 0633 0733
4/8/91 1452  4 00 32  63 AOS Backup FSTV or w/W5RRR US Bridg 0552 4/8 0752 0852
4/8/91 1512  4 00 52  63 LOS Backup FSTV or w/W5RRR US Bridg 0612 4/8 0812 0912
4/8/91 1925  4 05 05  66 Begin Pre-Sleep Activity            1025 4/8 1225 1325
4/8/91 1930  4 05 10  66 Start SAREX Stow                    1030 4/8 1230 1330
4/8/91 2000  4 05 40  66 Finish SAREX Stow                   1100 4/8 1300 1400
4/8/91 2225  4 08 05  68 Begin Sleep Period                  1325 4/8 1525 1625
4/9/91 0625  4 16 05  73 Begin Post-Sleep Activity           2125 4/8 2325 0025
4/9/91 0925  4 19 05  75 End Post-Sleep Activity             0025 4/9 0225 0325
4/9/91 1325  4 23 05  77 Deorbit Burn                        0425 4/9 0625 0725
4/9/91 1430  5 00 10  78 EDW Landing                         0530 4/9 0730 0830

** PT (Pacific Time), CT (Central Time) and ET (Eastern Time) starts as stan-
dard time then changes to daylight savings time on April 7, 0200 local time.

============================================================
###
--
Gary Morris                    Internet: garym@telesoft.com
Lockheed, Houston, Texas       UUCP:     lobster!avocado!gamorris
N5QWC/W5RRR                    Phone:    +1 713 283 5195

------------------------------

Date: 23 Mar 91 01:21:04 GMT
From: epic!karn@bellcore.bellcore.com
Subject: TAPR meeting notes
To: packet-radio@ucsd.edu

In article <17671@sdcc6.ucsd.edu>, williams@beowulf.ucsd.edu (Paul Williamson) writes:
|> 
|> A detailed blow-by-blow account of the 1991 TAPR Annual Meeting in Tucson
|> is available for FTP on tomcat.gsfc.nasa.gov in /public/tapr/blowby.txt
|> and on thumper.bellcore.com in /pub/ka9q/incoming/blowby.txt (until Phil
|> moves it to a permanent location).

I've moved it to /pub/ka9q/misc/blowby.txt.

Phil

------------------------------

Date: 18 Mar 91 00:48:18 GMT
From: usc!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!uupsi!phage!helix.cshl.org!markiewi@ucsd.edu
Subject: TCP/IP
To: packet-radio@ucsd.edu

Can someone offer me a hand? I am new to both the Internet, and to packet
so please bear with me. I have a PK232 and am ineterested in using the
KA9Q TCP/IP package with it. Does anyone have a basic document that they
could mail me on the proper techniques of its use? How does one obtain
their address? etc. Any help would be greatly appreciated..

	Thanks, Peter N2IFC

------------------------------

Date: 18 Mar 91 23:05:35 GMT
From: sdd.hp.com!usc!rpi!uupsi!phage!helix.cshl.org!markiewi@ucsd.edu
Subject: Thanks
To: packet-radio@ucsd.edu

Thanks to all the people who responded to my posting yesterday. I
think I have all the info I need, or atleast were I can find it.

Thanks again, Peter N2IFC

------------------------------

Date: 19 Mar 91 02:57:23 GMT
From: uvaarpa!haven!boingo.med.jhu.edu!aplcen!wb3ffv!howardl@mcnc.org
Subject: The Amateur Radio BBS - How to access
To: packet-radio@ucsd.edu

+------------------------------------------------------------------------------+
        HOW TO ACCESS THE WB3FFV AMATEUR RADIO TELEPHONE BBS !!!


 I have placed a BBS system on-line that is mainly oriented towards the 
Amateur Community (but there is other stuff on-line). As of now I have not
attempted to promote this system any place except in the amateur channels
(PACKET, USENET, & word of mouth), and will continue under this policy, as
I hope to keep it oriented toward amateur radio. The various software for
UP/DOWNload is available via telephone dialup and Packet TCP/IP, and through
user support I hope to keep the latest and greatest ham software on-line.
Below is the information that is needed in order to access the BBS via
Telephone -or- TCP/IP, please pass it around to as many ham's as possible.

 System Name: WB3FFV
 User Login: bbs
 Number: (301)-625-0817 -- 1200 & 2400 (Non-MNP)
 Number: (301)-625-9482 -- 1200,2400,4800,9600,19200,38400 V.32 (V.42bis/MNP5)
 Number: (301)-625-9663 -- 1200 & 2400 (MNP5), 9600 & 19200 (PEP) 
 Data Settings: 8 Bits, NO Parity, 1 Stop Bit
 Times: 24hrs/365days  (except for routine maintenance)
 Software: XBBS  (UNIX/Xenix Multiuser BBS)
 IP Address: 44.60.128.1 {wb3ffv.ampr.org} [for FTP access on 145.650 mhz ONLY]
 Misc. Info: Machine is an 80486 computer running UNIX V.3.2 and features 800 
             Meg of on-line storage. Most transfer protocols are available!!

 
 I attempt to keep the latest and greatest HAM software on-line, and encourage
all to upload anything new that they come up with, as it is of benefit to all.
Here is a sample of a couple pieces of software that is available for DOWNLOAD:

 KA9Q TCP/IP Software for the PC (Latest OFFICIAL release + TEST Versions) 
 KA9Q TCP/IP for the Atari-ST, MAC, & Amiga
 KA9Q TCP/IP for UNIX based systems
 KA9Q TCP/IP (The NOS release)  [UNIX, MS/DOS, Amiga]
 KA9Q TCP/IP (Version by G1EMM, PE1CHL, PA0GRI, Etc.)
 N2GTE Packet Mail Switch [GTEPMS] (Version 1.2)
 WA7MBL BBS for the PC (Versions 3.31, 4.31 & 5.1[2,3,4])
 W0RLI BBS for the PC (Versions 6.xx, 7.xx, 8.xx, 9.xx, 10.xx, 11.xx)
 MSYS BBS for the PC running KISS TNC's  (Version 1.07-1.10)
 AA4RE BBS for the PC (Version 2.10)
 Various BBS utilities and enhancements
 Several MORSE CODE Tutors
 TheNet software by NORD><LINK  (Version 1.01 & 2.06)
 Modifications for many HAM Rigs and Scanners
 Digital Signal Processing software (DSP)
 DX and contesting programs
 ARRL Newsletters & Gateway
 W5YI Electronic Edition

 There is much more available on the BBS, and I don't want to waste a lot of
PACKET BBS space trying to list it all, so if you are interested give it a
call and see for yourself !!!

If you are interested in using UUCP to connect to the BBS, this can also be
done as I support Anon-uucp. The login to the system is 'uucpanon', and there 
is NO password. The listing of avalible archives are stored in a file called
'FILES', and it is located in the /usr/spool/uucppublic. To retrieve the files
listing just use the following command:

uucp wb3ffv!~/FILES /usr/spool/uucppublic    

This will move a copy of my files listing into your uucppublic directory.  If
you have any questions or problems, feel free to contact me at one of the 
numbers/adresses below. Good Luck...

------------------------------

Date: 19 Mar 91 02:53:46 GMT
From: uvaarpa!haven!boingo.med.jhu.edu!aplcen!wb3ffv!howardl@mcnc.org
Subject: The N2GTE Packet Mail Switch
To: packet-radio@ucsd.edu

    Hello All,

As I promised about two weeks ago, here is a little more detail on the N2GTE
Packet Mail Switch.  I would have written back sooner, but getting the flu 
caused my bed to take priority over Email :-(

Many of you on here have talked about the problems with the TCP/IP section of
the MSYS package, but here is a BBS (if you want to run a BBS) that won't have
the problems listed since it actually uses NET (from Phil - KA9Q) so everything
should work.  

The BBS is a multi-user/multi-tasking system that runs inside of DesqView 2.3x
and uses DesqView like I have seen no other packaged do.  To achive very good
efficiency it uses multiple windows to acomplish it's tasks, and will open and
close user and forwarding windows as needed.  

Also one unique feature of the BBS is it's ability to learn new routes to other
BBS systems.  GTEPMS if not sure how to resolve a message, will send a request
to other GTEPMS systems in the area and ask them if they know how to resolve
the mail, and if so it will learn the path and add it to it's own tables.

I won't go into a big thing here on just what all the BBS will do, but will 
leave info below on how you can download the doc's if you desire.

Where I really like this BBS program is in it's ability to exchange mail 
between the BBS and NET.  I a message arrives on the BBS and it is destined
for an IP address (.AMPR, .AMPR.ORG, or whatever you specify), or the user
is listed in the forward file.  The BBS will place the message in the 
SPOOL\MQUEUE directory and setup the job for SMTP transfer.   Also if a job
arrives via SMTP and the next host can't be found in the HOSTS table ( this
assumes you have it set to place the unresolved jobs in RQUEUE), and the 
job gets placed in SPOOL\RQUEUE.  The GTEPMS system will scan the RQUEUE
directory and attempt to resolve the message.  So if the unresolved message
was for say W3XYZ @ WB3FFV.MD.USA.NA, it will accept that message and place
it in the BBS for forwarding in the BBS network.

As you can see this provides a complete gateway between the BBS and TCP/IP
worlds, and avoids many of the problem IP implementations in other BBS 
systems by actaully using NET.  I personally wanted to receive the local
BBS bulletins (and used the IP mbox, but it had many problems), but wasn't
willing to stop running NET/NOS to do this.  This BBS package (GTEPMS) has
allowed me to do both, and since becoming a beta tester for Doug's code I
have very much enjoyed the package.

One thing that should NOT be overlooked, this is a BIG system and requires
the mimimum configuration listed below:

80286 based system      (The faster the better)   {386 if at all possible}
Desqview 2.3x           (QEMM-386 5.x if using a 386)
2Meg of DRAM            (4Meg if also using NET)
G8BPQ PC-Node Software  (Version 3.57 to 3.59)
GTEPMS Version 1.2      (of course :-)

I personally use an 80386sx-20 with 4MB of RAM to run the system, but with
this configuration I can also use TC++ at the same time!

OK, so you want to know where you can get the software.  The code can be 
downloaded from my telephone BBS, and I will once again post in a seperate
message the information on how to reach my BBS.  I will also try and post 
the files on thumper and tomcat over the next couple days when I have time
to upload them, but for now it is only on the BBS.

Hopefully this will answer the questions some of you have on the BBS, and if
you decided to try it I would really like to hear what you think of it as well..


-------------------------------------------------------------------------------
Internet  : howardl@wb3ffv.ampr.org	|	Howard D. Leadmon
UUCP      : wb3ffv!howardl		|	Advanced Business Solutions
TELEX     : 152252474     		|	210 E. Lombard St - Suite 410
FAX       : (301)-244-8790              |       Baltimore, MD 21202 
PACKET    : WB3FFV @ WB3FFV.MD.USA.NA   |       Phone: (301)-576-8635

------------------------------

Date: 20 Mar 91 23:59:37 GMT
From: news-mail-gateway@ucsd.edu
Subject: TNC Emulators on PC's
To: packet-radio@ucsd.edu

Some time ago, a European software package was announced that could
emulate a TNC on an IBM PC or PC Clone.  Besides that package, are
there any other IBM clones TNC emulators around?

------------------------------

Date: 21 Mar 91 00:28:45 GMT
From: theory.tn.cornell.edu!payne@THEORY.TN.CORNELL.EDU
Subject: TNC Emulators on PC's
To: packet-radio@ucsd.edu

In article <9103202358.AA23474@ucsd.edu> GIDEN@WSUVM1.CSC.WSU.EDU (Robert Giden N7KCG) writes:
>Some time ago, a European software package was announced that could
>emulate a TNC on an IBM PC or PC Clone.  Besides that package, are
>there any other IBM clones TNC emulators around?

	Yes, there is.  I've written a program called PMP (Poor Man's Packet)
that is in use here in the Ithaca, NY area.  The gory details of the serial
protocol are not as cleanly implemented as Baycom (my program hangs the 
machine during RX and TX) and I don't have as many features as Baycom.
But overall, I think my program is much more cleanly implemented (overall
structure, user interface, configuration).

	Originally, I was going to make the program shareware.  Now, with
the usual lack of time, I'm giving it away as "guiltware"--send me what
you think it is worth.  I offer no guarantees;  I may never get around to
fixing bugs.  But I will give you some help:  full source code (Turbo C).

	If there is any interest, I will make it available via anonymous
FTP.
-- 
=  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =  =
Andrew C. Payne, N8KEI        UUCP:  ...!cornell!batcomputer!payne
                          INTERNET:  payne@tcgould.tn.cornell.edu

------------------------------

Date: 21 Mar 91 21:55:06 GMT
From: usc!wuarchive!waikato.ac.nz!comp.vuw.ac.nz!cc-server4.massey.ac.nz!G.Moretti@ucsd.edu
Subject: TNC Emulators on PC's
To: packet-radio@ucsd.edu

>>> Re PMP - A user's comments

An excellent program.  I've been using it for about a year and it
works well.  Several other users down in this part of the world have
been using it quite successfully too ...

One disadvantage (which apparently is shared by BAYCOM) is that you
cannot upload/download binary files (no YAPP/XMODEM ...) support. 

I've been using the second parallel port, but as the port address, the
active bit and which level is active are defined in the config file
(PMP.CFG) you should be able to use either serial or parallel port to
talk to the modem.  

The modem side is simply a 7910 based modem for 1200 baud.

These comments apply to PMP version 0.93.  Andy may have released a
later version.

Cheers
Giovanni  ZL2BOI



-- 
------------------------------------------------------------------------------
Giovanni Moretti, Consultant       | G.Moretti@massey.ac.nz, Pkt-ZL2BOI@ZL2BFJ
Computer Centre,  Massey University| Ph 64 63 69099 x8398, FAX 64 63 505607
Palmerston North, New Zealand      | QUITTERS NEVER WIN, WINNERS NEVER QUIT
------------------------------------------------------------------------------

------------------------------

Date: 20 Mar 91 15:26:23 GMT
From: usc!apple!well!kdavis%well.sf.ca.us@ucsd.edu
Subject: WANTED: Docs for NETPC (DL3DBT v891105)
To: packet-radio@ucsd.edu

I am running the net.exe called netpc developed in Germany by
DL3DBT and group.  I have it running fine on two ports with
tcp/ip and net/rom.

I need the documentation for this (in English, I hope).  Many features
like NOS are handled with this program and it has color and windowing
support.

If anyone knows where I can ftp the docs please contact me.  Thanks!

-- Ken
 

------------------------------

Date: 21 Mar 91 17:57:32 GMT
From: agate!apple!veritas!amdcad!sono!collins@ucbvax.berkeley.edu
Subject: Where can I download Baycom?
To: packet-radio@ucsd.edu

I am looking for a copy of Baycom and noticed in a previous
posting that someone (don't remember who, unfortunately)
mentioned downloading it. Does anyone know of a site which
has Baycom and which could e-mail a uuencode'd copy (I do
not have ftp access)?

Thanks in advance,

Michael Stratford Collins
collins@sono.uucp
sun!sono!collins

------------------------------

Date: (null)
From: (null)
> And while I'm pontificating (:-) the left most callsign (in the above 
> examples
> VK6ZJM) should ONLY be considered for routing purposes if it is shown as part
> of the domain segment (eg VK6ZJM.VK6BBS.#WA.AUS). Once the '@' is reached in
> the right to left scan, routing should stop. The reason is this: the 
> originator
> of the message may know that VK6ZJM has moved QTH - routing software wouldn't
> always know this.
> 
I think that when someone moves the first person they tell (in the packet
world) is the SYSOP of their local BBS, otherwise that BBS is going to keep
trying to forward mail to them when they're not there. Being able to forward
on the TO field is often very useful - remote SYSOPs often like to have mail
addressed to SYSOP forwarded on to them, for example.

----
Brian Lloyd
Software Management & Control, 		# By e-mail : blloyd@axion.bt.co.uk
Software Technology Division,		# By Phone  : +44 (0)473 646650
SSTF Building, BTRL, Martlesham Heath, 	# By Fax    : +44 (0)473 643019
Ipswich, Suffolk. UK. IP5 7RE		# By Packet : G1NNA@GB7NNA.GBR.EU

------------------------------

Date: 19 Mar 91 05:01:47 GMT
From: gatech!udel!haven!ni.umd.edu!sayshell.umd.edu!louie@ucsd.edu
To: packet-radio@ucsd.edu

References <7492.27e484b1@cc.curtin.edu.au>, <1991Mar18.150624.23335@axion.bt.co.uk>, <1991Mar18.215239.19274@casbah.acns.nwu.edu>
Subject : Re: Hierarchical Forwarding pounds (#)

In article <1991Mar18.215239.19274@casbah.acns.nwu.edu> hpa@casbah.acns.nwu.edu (Peter Anvin) writes:
>In proper domain-style addressing, a la the Internet, this would rather be:
>
>Do I know where VK6ZJM.WA.AUS is?     No
>Do I know where WA.AUS is?            No
>Do I know where AUS is?               Yes
>Forward in direction AUS
>

Bzzzzzt - wrong.  In domain-style "addresses", names are just names,
and DO NOT imply routes.  There are names, addresses, and routes; it
is important to keep the distinction between each of them. 

Internet style names are broken into an administrative heirarchy which has
(by design and absolute intent) nothing to do with routing or addresses.  

If you are going to cite Internet style domain names, please don't change
the meaning while you're at it.

Yes, some of us are really sensitive about this distinction.

louie
WA3YMH

------------------------------

Date: 19 Mar 91 10:35:36 GMT
From: ucselx!bionet!apple!mips!spool.mu.edu!munnari.oz.au!manuel!csc.canberra.edu.au!echo!skcm@ucsd.edu
To: packet-radio@ucsd.edu

References <1991Mar15.025040.16086@maverick.ksu.ksu.edu>, <1991Mar16.202548.18162@ims.alaska.edu>, <7492.27e484b1@cc.curtin.edu.au>
Subject : Re: Hierarchical Forwarding pounds (#)

In <7492.27e484b1@cc.curtin.edu.au> Murray_RJ@cc.curtin.edu.au (Ron Murray) writes:
>> the octothorpe, '#'.
>2. Someone in Australia mis-read the documentation and decided that this name
>   change was necessary. This is probably the more likely.

FAR FAR more likely.  :-)  Browsing thru the mail on my BBS (VK1KCM) I notice
South Australia and Western Australia both use the "#" at the state level 
while everybody else only uses it below the state. (#SA, #WA and ACT, NSW etc)

It's rare, however, for there to be any identifiers below the state level.
My address here in Canberra is;
vk1kcm@vk1kcm.act.aus.oc

Also the "Asianet" sysops, mainly Brian Beamish Vk4BBS decided that we wouldn't
use .au as our domain.  Instead we have to use .oc (for Oceania).  Needless to
say none of these people are on the internet. :-(


Carl.

------------------------------

Date: 15 Mar 91 03:12:15 GMT
From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!uakari.primate.wisc.edu!umriscc!maverick.ksu.ksu.edu!matt.ksu.ksu.edu!steve@ucsd.edu
To: packet-radio@ucsd.edu

References <47@norand.UUCP>, <29868@ucsd.Edu>, <1991Mar13.212921.31032@cunixf.cc.columbia.edu>ck.ks
Subject : Re: Digital repeater network


>Has anyone looked into the feasibility of creating a digital repeater network?
>It seems to me that this would allow most any ham to talk to most any other,
>anywhere, using a simple handheld radio. This seems like a logical extension
>of the current plans to create an analog system using dynamic links to a
>long distance backbone.  The problem with this scheme is:  what happens
>if a link in the backbone fails; and if more than one user wants to use the
>system at the same time?  It would be a very resource intensive system, 
>anyway.

I have thought of this idea.  With current A/D and DSP technology, it 
would be easy to build a fully Digital Audio Repeater (DAR).  Just convert
the received audio with an A-to-D, add filtering/CW tones/ect 
with a DSP and spit out the result using a D-to-A.  If 
output to a network is wanted, just send the digital streams 
to a RF modem as well as the transmitter.  Also, voice mail could  
easily be implemented with the addition of secondary storage. (it could
even be transferred as normal mail over conventional packet channels.)

>In short:  why couldn't the Amateur community set up the equivalent of a
>digital cellular network with modest user requirements, linked exclusively
>by radio and therefore immune to damage to the hard-wired systems such as
>the telephone network.

A similar 'what if' was presented at the _9th Computer Networking Conference_
by Jon Bloom, KE3Z.  The technology is getting there, but it will take
even more time before the idea catches on.  We have a large base of
old technology voice repeaters that will not go away.  :-)

-Steve Schallehn, KB0AGD
 Kansas State University

------------------------------

Date: (null)
From: (null)
--Kauto, OH5LFM

--
****************** Kauto Huopio (huopio@kannel.lut.fi) **********************
*  Mail: Kauto Huopio, Punkkerikatu 1 A 10, SF-53850 Lappeenranta,Finland   *
*****************************************************************************

------------------------------

Date: 20 Mar 91 02:49:36 GMT
From: swrinde!elroy.jpl.nasa.gov!sdd.hp.com!zaphod.mps.ohio-state.edu!casbah.acns.nwu.edu!hpa@ucsd.edu
To: packet-radio@ucsd.edu

References <1991Mar18.150624.23335@axion.bt.co.uk>, <1991Mar18.215239.19274@casbah.acns.nwu.edu>, <1991Mar19.050147.911@ni.umd.edu>
Subject : Re: Hierarchical Forwarding pounds (#)

In article <1991Mar19.050147.911@ni.umd.edu> louie@sayshell.umd.edu (Louis A. Mamakos) writes:
>Bzzzzzt - wrong.  In domain-style "addresses", names are just names,
>and DO NOT imply routes.  There are names, addresses, and routes; it
>is important to keep the distinction between each of them. 
>
>Internet style names are broken into an administrative heirarchy which has
>(by design and absolute intent) nothing to do with routing or addresses.  
>
>If you are going to cite Internet style domain names, please don't change
>the meaning while you're at it.

I stand corrected -- to a degree.  What I should have said, I guess, would
be something like ``this is the intent of hierarchial **addressing**''.

As you correctly point out, Internet host names are hierarchial but do not
necessarily imply addressing.  They do if and only if they point to a
non-IP subdomain for mail traffic, such as fidonet.org, where routing is
provided through UUCP to different gateways depending on a specified
subdomain.

In the store-and-forward landline network Fidonet, addresses are
hierarchial but numerical on the form

    NNN:NNN/NNN.NNN      (the punctuation allows for abbreviation only)

The Fidonet address is left-major, opposite the direction of the Internet
and Amateur Packet hierarchial names, but partially similar to the IP
numbering system (NNN.NNN.NNN.NNN).

If a system is to send mail to, say, 2:206/203.1 it uses an algorithm like
this:

    [THIS IS VERY SIMPLIFIED AS ANYONE FAMILIAR WITH FIDONET WOULD SEE
     IMMEDIATELY]

    Do I have a route to 2:206/203.1?     No
    Do I have a route to 2:206/203.0?     No
    Do I have a route to 2:206/0.0?       No
    Do I have a route to zone 2?          YES - 1:115/500.0 -> forward

The amateur AX.25 network is different from Fidonet, Internet and UUCP in
topology, nature of the nodes, the information each node has, and
addressing format.  Thus what applies to one does not necessarily aplpy to
the other.  That doesn't prevent us from learning from each other and find
a good combination of techniques needed for each individual network.

                        /Peter

-- 
hpa = H. Peter Anvin (in case you wondered) * Heja Sverige!
INTERNET:   hpa@casbah.acns.nwu.edu   FIDONET:  1:115/989.4
HAM RADIO:  N9ITP, SM4TKN             RBBSNET:  8:970/101.4

------------------------------

Date: (null)
From: (null)
The idea of scanning from left to right is to find the most direct route to
the destination. If I was to forward a message to you, the BBS would perform
the following steps :

Do I know where VK6ZJM is?
No - do I know where VK6BBS is?
No - do I know where #WA is?
No - do I know where AUS is?
Yes - forward the message in that direction.

If, on the other hand, I had a direct link to VK6BBS I would forward the
message there, rather than to Australia, as VK6BBS is much closer to you
Australia in general.

The main reason for having the # before the second field is to eliminate any
problem which may arise from having a local hierarchical address which is
the same as a country or continent designator. If, for example, you had a
local address of NA (for Northern Australia, say), then the BBS would try to
send the message to North America, as that is what NA is supposed to be.

I hope this helps a bit.

Brian
(G1NNA@GB7NNA.GBR.EU)

------------------------------

End of Packet-Radio Digest
******************************
